locale specification

Hello,

In the past I’ve done some work in software localization (both
translating or implementing gettext support). It’s something that
personally interests me a bit. Some time ago I took a look in the
localization part of the CSL spec, some comments:

  • 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
    http://www.gnu.org/software/hello/manual/gettext/Header-Entry.html ,
    but not all applies in CSL locale files). It’s also nice to give some
    attribution to the translator.

  • I would also add the date of the last update of the localization
    file (I suggest a timestamp like the Citation Style update field).

  • 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.

  • 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.

  • 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
    http://www.gnu.org/software/hello/manual/gettext/Plural-forms.html ,
    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.

For the first three items: something similar to the CSL element
but in the locale file could work. E.g.:



The Name
The email
Some URI


The Name
The email
Some URI

timestamp
1.01

  • 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
    http://www.gnu.org/software/hello/manual/gettext/Header-Entry.html ,
    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 would also add the date of the last update of the localization
    file (I suggest a timestamp like the Citation Style update field).

Good idea.

  • 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).

  • 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? :slight_smile: I did write some translator instructions, but that
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
translations, rendering citations seems overkill (you could just have a
static page with formatted examples).


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.
http://forums.zotero.org/discussion/10859/errors-in-spanish-bibliographylocale/?Focus=53633#Comment_53633),
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.

RintzeOn Fri, Jul 30, 2010 at 7:25 PM, Carles Pina <@Carles_Pina>wrote:

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
    http://www.gnu.org/software/hello/manual/gettext/Header-Entry.html ,
    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? :slight_smile: 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).


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.
http://forums.zotero.org/discussion/10859/errors-in-spanish-bibliographylocale/?Focus=53633#Comment_53633),
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.

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).

I could imagine that at some point a citationstyles.org repository
could also host the locales stuff, with a nice little UI for creating
and editing them?

Bruce

Hello,

I forgot to ask something.On 31 July 2010 02:01, Rintze Zelle <@Rintze_Zelle> wrote:

  • I would also add the date of the last update of the localization
    file (I suggest a timestamp like the Citation Style update field).

Good idea.

Do you want me to open an issue in
http://bitbucket.org/bdarcus/csl-schema/issues?status=new&status=open
?

Or to send a patch here?

I’m not sure which is the standard process.

Thanks,

Not sure there is one :wink:

But we’re trying to be good about using the issue tracker, so please
open an issue there, and I guess attach to the patch to that?

Thanks!

Bruce