Hello,
- Would be nice to have the last translator’s name and email in the
locale files (or locale maintainer). Gettext does it, and I find it
useful when I report some errors in some .po file (you can see some
more headers in
Header Entry (GNU gettext utilities) ,
but not all applies in CSL locale files). It’s also nice to give some
attribution to the translator.
Pre-CSL 1.0, CSL locales were translated via BabelZilla, piggybacking with
the Zotero files. The BabelZilla translators are credited in the “About
Zotero” window. So I don’t think attribution specifically for CSL locales
has come up before, but we could allow for it. However, if the goal is
attribution (instead of a way to get hold of the most recent translator), we
probably wouldn’t want to limit attribution to the last translator (who
might have made only a minor contribution).
I agree. I was trying to mirror the gettext header entry, but it could
be done like the CSL files: author, contributors and maybe last
translator.
When I report some error about some .po file: I usually use the
language-team or the last translator. Usually one of both has access
the repository, they are working on the next release, etc.
In this case, because the locale files are quite small I don’t think
that it’s needed the concept team.
- For which CSL version is this locale file? Would be nice that the
locale file says for which CSL version is for. Easier to manage.
Software could warn the user that the locale file is not updated for
the current CSL version.
Specify “this”. CSL 1.0 locale files can be obtained from
http://bitbucket.org/bdarcus/csl-locales/src/tip/trunk/, and for CSL 1.0 the
version of the locale file is indicated on the root element (see e.g.
http://bitbucket.org/bdarcus/csl-locales/src/tip/trunk/locales-nl-NL.xml),
i.e. (as for CSL 0.8 styles, CSL 0.8 locale files lack this
attribute).
(I should review the mails that I write at the airports…)
You are right, and it’s what it says in the documentation (
http://citationstyles.org/downloads/specification.html#locale-files-basic-structure
). I thought that the 1.0 in the locale file was the locale file
version, not the CSL version that this locale is for. My bad.
- Would also be nice to have a test-suite for translators, so they
could see all items in some context. Like the demo.html webpage of
citeproc-js but with all possible elements. It really would help to
translate.
Are you volunteering? 
I did write some translator instructions, but that
Not in short term, but maybe some day I’ll personally volunteer.
is nothing like what you’re proposing. Any reason you would like to use
citeproc-js? Without the ability to have translators plug in their own
I mentioned citeproc-js as an example and because it’s the one that
I’m more familiar.
As a translator I appreciate if I can see the result of my work
easily. A webpage with the strings and then being able to upload the
locale file to see the same webpage in the new language is enough.
Specially if this system can cover all the strings (the same raw
source string could have two meanings up to the context, but I think
that this doesn’t happen).
- Big one, but not sure how relevant it is: I see that the current
locale files only supports the English singular (one) and plural (not
one). In some languages there are multiple plurals. Described in
Plural forms (GNU gettext utilities) ,
example copied-pasted from there:
In Polish we use e.g. plik (file) this way:
1 plik
2,3,4 pliki
5-21 pliko'w
22-24 pliki
25-31 pliko'w
A more common case is to have a singular, plural form for 2 elements,
and then plural form for other forms (more than 2 or 0).
The multiple plurals is more a “heads up” than asking to specify it in
short term.
Similar requests have come up before (e.g.
Errors in Spanish bibliographyLocale - Zotero Forums),
but supporting all this requires: a) detailed language-specific knowledge
and b) a way to encode all the required logic in the locale files. I am not
sure something this complex is in the scope of CSL.
about a) : we could follow what gettext and others are doing… (for
the plurals). And still there will be some problems for the ordinal
numbers and others…
about b): I agree with that, so no more comments about it at the moment.
