Hello,
I’ve updated the locales_nl.xml to the new xml format. I ran into a
few issues.
We should include contact info for the person who did the
translation. Especially because some parts of it might be perceived
erroneous even by native speakers even though the translation is
correct. E.g. the Dutch word for “volume” is “volumen” although I’m
sure many Dutch would think “volume” is the right word (“volume” is
actually used for sound volume or for contents of an object) and
"volumen" just the plural form of the word (actual plural is
"volumina"). I think therefor that it would be wise the confer with
the orignal translator before accepting “corrections”.
If the single and multiple entries are the same or are nonsensical
for the particular language, should I just type the same thing twice,
or simply place it in the directly?
Similarly, if there is no abbreviation available, should I just omit
the entry, or include the term in its unabbreviated form with the
form=“short” attribute? I think the last option is best because in
that case the citeproc implementation can complain rightfully that
the locales file is incomplete if an expected entry is missing.
I’ve now settled on using the shortest abbreviations avialable in
Dutch. So “p.” for “pagina” (page), although “pag.” is also an
official abbreviation. I don’t know which is used more often in Dutch
styles.
Some abbreviations require a “.” at their end. I assume this period
should be included in the translation.
Johan
We should include contact info for the person who did the
translation.
If you’d like, I can allow an option info element on the standalone
locales files. Though I’d probably need to strip it down.
If the single and multiple entries are the same or are nonsensical
for the particular language, should I just type the same thing twice,
or simply place it in the directly?
Probably better to do the former? I dunno.
Similarly, if there is no abbreviation available, should I just omit
the entry, or include the term in its unabbreviated form with the
form=“short” attribute? I think the last option is best because in
that case the citeproc implementation can complain rightfully that
the locales file is incomplete if an expected entry is missing.
Right.
Some abbreviations require a “.” at their end. I assume this period
should be included in the translation.
I feel like this goes back to Simon’s earlier issues on initialization.
I tend to think the locales strings ought not to include them unless
you know they will always be used. Not sure though.
Bruce
I presume that would be:
although at the moment there are no short verb forms in the file.
Simon
We should include contact info for the person who did the
translation.
If you’d like, I can allow an option info element on the standalone
locales files. Though I’d probably need to strip it down.
Maybe an element that allows only author/contributor/updated
elements?
The other option would be to include creator info in comments, but the
downside then is that it’s not available to the application.
If the single and multiple entries are the same or are nonsensical
for the particular language, should I just type the same thing twice,
or simply place it in the directly?
Probably better to do the former? I dunno.
I would suggest the latter. It’s fairly simple to write a getTerm() function
that returns the string if there are no child elements to the , or the
correct single/multiple element if there are. There’s not much sense in
replicating words in the locales file unless we absolutely have to.
Similarly, if there is no abbreviation available, should I just omit
the entry, or include the term in its unabbreviated form with the
form=“short” attribute? I think the last option is best because in
that case the citeproc implementation can complain rightfully that
the locales file is incomplete if an expected entry is missing.
Right.
Perhaps form should be a list? In a situation like this you could type
form=“short long verb” and have it apply to all. Or perhaps this would get
confusing?
Some abbreviations require a “.” at their end. I assume this period
should be included in the translation.
I feel like this goes back to Simon’s earlier issues on initialization.
I tend to think the locales strings ought not to include them unless
you know they will always be used. Not sure though.
Some styles output, e.g., “p105” which may look wrong if the abbreviations
are changed (“pag105”) but would look even worse if the abbreviations had a
trailing period (“pag.105” with no space between pag and 105). So, I’d say
you leave the periods out, unless the term would be confused for another
without them, or there’s some other very convincing reason they’re
necessary.
Simon