This is a question for Bruce and Dan or Sean. Locales.xml currently only
specifies locale-specific terms, but there is a need to specify some
locale-specific rules/options as well (e.g. choice between British or
American punctuation, date-order). It might also be handy to put the
locale-specific quotes (guillemots, “”, ‘’, etc) in a different container
than terms. However, the current xml-format is a bit restrictive. The
question Frank and I had was whether it is possible to change things a bit,
e.g. from:
at
to something like:
at
The specific questions we came up with: 1) is this an acceptable format? and
2) is the CSL processor in Zotero the only piece of code that reads out
locales.xml? If so, it would probably not be such a big hurdle to switch to
a different layout.
Rintze
This is a question for Bruce and Dan or Sean. Locales.xml currently only
specifies locale-specific terms, but there is a need to specify some
locale-specific rules/options as well (e.g. choice between British or
American punctuation, date-order). It might also be handy to put the
locale-specific quotes (guillemots, “”, ‘’, etc) in a different container
than terms. However, the current xml-format is a bit restrictive. The
question Frank and I had was whether it is possible to change things a bit,
e.g. from:
at
to something like:
at
The specific questions we came up with: 1) is this an acceptable format?
Yes.
and 2) is the CSL processor in Zotero the only piece of code that reads out
locales.xml?
What do you mean by “reads out”?
Bruce
This is a question for Bruce and Dan or Sean. Locales.xml currently only
specifies locale-specific terms, but there is a need to specify some
locale-specific rules/options as well (e.g. choice between British or
American punctuation, date-order). It might also be handy to put the
locale-specific quotes (guillemots, “”, ‘’, etc) in a different container
than terms. However, the current xml-format is a bit restrictive. The
question Frank and I had was whether it is possible to change things a bit,
e.g. from:
at
to something like:
at
The specific questions we came up with: 1) is this an acceptable format?
Yes.
and 2) is the CSL processor in Zotero the only piece of code that reads out
locales.xml?
What do you mean by “reads out”?
Depends upon, parses, or attempts to handle. The worry is that making
this change to the layout of the locales files might crash Zotero.
and 2) is the CSL processor in Zotero the only piece of code that reads
out
locales.xml?
What do you mean by “reads out”?
Sorry for not being clear (and asking a probably superfluous question). What
I was wondering was whether Zoteros CSL processor (I guess that would be
csl.js) is indeed the only piece of code in Zotero that uses the information
in the locales.xml files. If so, the format of loocales.xml can be easily be
changed (no backwards-incompatibility issues or other nasty stuff), as long
as Frank’s CSL processor can cope with the new format. The only burden would
be rewriting the currently translated files.
Rintze
This is a question for Bruce and Dan or Sean. Locales.xml currently only
specifies locale-specific terms, but there is a need to specify some
locale-specific rules/options as well (e.g. choice between British or
American punctuation, date-order). It might also be handy to put the
locale-specific quotes (guillemots, “”, ‘’, etc) in a different container
than terms. However, the current xml-format is a bit restrictive. The
question Frank and I had was whether it is possible to change things a bit,
e.g. from:
at
to something like:
at
The specific questions we came up with: 1) is this an acceptable format?
Yes.
I’ve converted the locale files in the new processor sources to this
new layout, and adjusted the tests and the processor code to work with
it.
How are we going to manage this transition? I presume changing this
will break every implementation (though it’s of course an easy fix).
Bruce
I’ve converted the locale files in the new processor sources to this
new layout, and adjusted the tests and the processor code to work with
it.
How are we going to manage this transition? I presume changing this
will break every implementation (though it’s of course an easy fix).
Include a version level specifier in CSL files at 0.9 or above, and
require implementations that handle 0.9 or above to declare the CSL
versions they support, and raise an error on verson failure?