Re: [Translation-i18n] pgettext() availability in Debian?
Hello Clytie, Thanks for the forward. You know I cannot read so many mailing lists :-) Hello Adam, > > I need to be able to call > > [d[c]]pgettext(), as described in the gettext manual[1]. > > > > Despite having all the gettext-related packages that I can find > > installed on my system, these functions do not appear to be declared > > anywhere.[2] Is there a package I should have installed? The manual [1] says: "The gettext.h include file contains the lookup macros for strings with contexts..." The gettext.h file is documented in [2]. In particular, "Do not install the gettext.h file in public locations. Every package that needs it should contain a copy of it on its own." You get a copy of gettext.h either from /usr/include/share/gettext/gettext.h (if it's missing there, it's a packaging bug of the Debian package), or from gnulib [3] module 'gettext-h' [4]. Bruno [1] http://www.gnu.org/software/gettext/manual/gettext.html#Contexts [2] http://www.gnu.org/software/gettext/manual/gettext.html#lib_002fgettext_002eh [3] http://www.gnu.org/software/gnulib/ [4] http://www.gnu.org/software/gnulib/MODULES.html#module%3Dgettext-h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] gettext with non-en source language
MJ Ray asked:
> > Question raised on -l10n-esperanto recently: can gettext be used for
> > localising a program with a utf-8 non-English source language?
> > That is, the thing in the _("...") has accents and isn't English.
Technically, it is possible to use a non-English source language.
You have to be careful to
- pass --from-code=UTF-8 to xgettext when creating the PO files,
- always keep the PO files in UTF-8 encoding, never convert them to
ISO-8859-1 or so.
The bigger problem is to get translators which understand this
non-English language. Translators from, say, Spanish to Hungarian
are more difficult to find than translators from English to Hungarian.
Bruno
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] gettext with non-en source language
Christian Rose wrote: > gettext's English-centredness (which to large parts is historical, but > in some cases still exists, like in the handling of plural forms) is > both a blessing for our community where English is the UI default, as > much as it is a nuisance in other real-life software development where > the local language is the one that is targeted primarily, and is the > one that you would want in the msgids and base your other future > translations on. What you call "gettext's English-centredness" is only a recommendation in the doc. You _can_ use another language as the language of the source files and the msgids in the PO files. Did you try it? Did you encounter problems? Sure there are people who start a web server software in Czech and then want to localize it to German. They can do so. But I will not recommend in the gettext doc to do like this. English and American are the world's most understood languages nowadays and for the next decades, not Czech, German, Spanish or whatever. It is short-sighted to start a fresh project with user interface strings in any other language than English. Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: translating via an intermediate language
Clytie, > It's great to know gettext can already do this: it means we can start > testing the process. > > This facility is needed for the cases when translating from a non- > English language _would_ produce a better result. > > For my language alone, there are many possible translators who would > work much better from Chinese or Russian to Vietnamese than from > English. It's simply a matter of which languages you have had the > opportunity to learn. Now _that_ is an interesting idea! Gettext can already nearly do this, too, if you write three small scripts/ programs to - convert an English-based .pot file into a Russian-based .pot file, - convert an English->Vietnamese PO file to a Russian->Vietnamese PO file, (to be used when such a translator starts her work), - convert an Russian->Vietnamese PO file back to an English->Vietnamese PO file (to be used when a translator is done with her work). And then the translator has these additional conversions steps all the time. It would be better, for the future, that the translator has only one additional step to perform: When she gets a new PO file, she converts it to a mixed English/Russian->Vietnamese PO file. Such a mixed English/Russian->Vietnamese PO file would 1) permit the translator to peek into the English original when something is unclear, 2) also work when not some of the Russian translations are missing or fuzzy, 3) get rid of the "convert back" step, since msgfmt could directly grok the mixed English/Russian->Vietnamese PO file. The syntax for a mixed PO file could like this: msgid "Hello, world!" msgid[ru] "Здравствуй, мир!" msgstr "Chào thế giới !" The PO file editors would have to be taught to display msgid[ru] in preference to msgid if the translator has said so. Bruno
Re: [translate-pootle] [Translation-i18n] gettext with non-en source language
F Wolff wrote:
> > What you call "gettext's English-centredness" is only a recommendation
> > in the doc. You _can_ use another language as the language of the source
> > files and the msgids in the PO files. Did you try it? Did you encounter
> > problems?
>
> Well, I did not try it, but the example used here (Czech as source
> language) won't work, because it has three plural forms.
Good point. But this problem can be overcome by defining a function
const char *
cz_ngettext (const char *singular, const char *paucal, const char *plural,
unsigned long n)
{
const char *translation = ngettext (singular, plural, n);
if (translation == singular || translation == plural)
return (n == 1 ? singular : n >= 2 && n <= 4 ? paucal : plural);
else
return translation;
}
then using cz_ngettext in the source code, and finally passing the option
--keyword=cz_ngettext:1,3 to xgettext.
> I foresee a possible scenario for example
> where someone in francophone Africa writes in French which will be the
> common language to use to translate into local languages. Not the best
> choice to get you translations in all the world's languages, perhaps,
> but the correct choice for their circumstances. I'm speaking quite
> hypothetical now, of course.
Quite hypothetical, indeed. Africa is not yet connected to the programmer's
net. I got a single mail from Africa in 14 years. (Not counting the masses
of Nigeria connection spam :-))
> Although it would be interesting to see how
> many people will be able to contribute for the first time if
> understanding of English is removed as obstacle.
That appears to depend on the country's culture or economic situation. There
must be good knowledge of English in India, yet there are reportedly only
7 free software developers in whole India.
Bruno
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] gettext with non-en source language
Jean-Christophe Helary wrote: > In the next decades and starting very soon, the world's most > understood languages will be Chinese and Hindi, and especially those > two will have a huge influence on the IT world. And only the people > who don't read Chinese on Hindi are blind to that. > > It is very short sighted to not take that into account. Chinese and Hindi the most understood languages of the world? I doubt that. Languages have in the past spread 1. through conquests, 2. through culture (music, literature, cinema, ...). China (PRC) is an aggressive state (*), but IMO it will not conquer the U.S. nor Europe in the next 50 years; and India is not an aggressive state. Chinese culture is mostly unknown in the rest of the world. Indian culture spreads out, but very slowly; Bollywood will take a long time to replace Hollywood. The influence of languages is large in IT world if 1. the language is wide-spread in general, or 2. the language is wide-spread in IT, or 3. the top computer scientists come from a culture that speaks this language. Neither the Chinese nor the Hindi language fits these criteria. Bruno (*) Don't forget that 3000 students were murdered by the government of the "People's Republic of China" in June 1989! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] translating via an intermediate language
Hello Clytie, > Another translator has > already mentioned doing this in Emacs: keeping the backup language PO > file as a reference. So if we could request: > > msgid[en] > msgid[xx] > msgstr > > in an editor, specifying the secondary msgid language in the prefs, ... It can not be done purely in the editor. Because if, say, the Russian translator updates her translation, correcting a mistake she did in an earlier translation, and you translate from Russian to Vietnamese, you need to be alerted of this. msgmerge needs to set the 'fuzzy' flag when this happens. If it were just the editor which displays a synthesis of vi.po and ru.po, this could not work. We really need to save a (partial) copy of ru.po in vi.po. > Current candidates for the secondary msgid language, which would > increase our translation resources, and make it possible for many > more translators to participate, include Russian, Spanish, > Portuguese, French, Afrikaans, Chinese and Hindi. Absolutely! Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] translating via an intermediate language
Hi Danilo, > > The syntax for a mixed PO file could like this: > > > > msgid "Hello, world!" > > msgid[ru] "Здравствуй, мир!" > > msgstr "Chào thế giới !" > > I think the following would make more sense (except that the syntax > would conflict plural forms syntax): > >msgid "Hello, world!" >msgstr[ru] "Здравствуй, мир!" >msgstr[vi] "Chào thế giới !" The syntax could be reconciled with plurals. There is no problem writing msgstr[fr][0] "singulier" msgstr[fr][1] "pluriel" But this syntax has two drawbacks: - It doesn't make it clear whether 'ru' or 'vi' is the target language. Whereas the syntax with msgid[ru] makes it more clear what is the input for the translator and where she puts her translation. - As you mentioned, there is a risk that people confuse it with a "multi-language PO file". > Another thing to be careful about is many-to-one-to-many mappings, > eg. what if both "Blah" and "Foo" translate to something like "Bar" in > language "trt": > > msgid "Blah" > msgid[trt] "Bar" > msgstr ... > > msgid "Foo" > msgid[trt] "Bar" > msgstr ... > > And we use "trt" as our base language, then "Bar" is clearly not a > unique msgid, which is exactly why I feel msgstr there makes more > sense. There is no uniqueness requirement for msgid[trt], indeed. In a case like this, the translator would have to look at the msgid line too, not only at her preferred msgid[trt] line. > (as a sidenote, I already have a working PHP and gettext-based system > which does gettext_in_alternate_language(msgid) instead of displaying > msgid; this can simply be done in PO tools with pointers to two PO > files: "use this one for base messages, translate into this one") Interesting! And what are the practical experiences you or translators made with it so far (except that it's useful :-))? Bruno
Re: translating via an intermediate language
Dwayne Bailey wrote:
> > The syntax for a mixed PO file could like this:
> >
> > msgid "Hello, world!"
> > msgid[ru] "Здравствуй, мир!"
> > msgstr "Chào thế giới !"
>
> these are the issues I see:
>
> * Plurals - mentioned already
I can reduce the number of plural forms to 2, by choosing for the
"singular" the one with n = 1 and for "plural" the one which is chosen
most often for n -> ∞.
> * fuzziness - if [ru] is fuzzy do you merge it or leave it out and how
> do you differentiate from [ru] fuzziness or fuzziness that relates to
> the target language.
If the Russian message translation is fuzzy, I don't store it in the
PO file. First the Russian translator has to make a correct translation,
then only it makes sense that other translators see it.
A message in the mixed PO file can become fuzzy if the msgid changed,
but also if the msgid[ru] changed while the msgid stayed the same.
The Vietnamese translator can distinguish these two cases (i.e. know
whether the English has changed, or the Russian one, or both) by looking
at the previous msgids.
"Previous msgids" will be a new feature in gettext 0.15.1. Quoting the
NEWS file:
"msgmerge has a new option --previous that has the effect of saving the
previous msgid of message when making them fuzzy. These previous msgids are
stored in the resulting PO file, using a pseudo-comment syntax like this:
#, fuzzy
#| msgid "too many arguments"
msgid "too few arguments"
msgstr "trop d'arguments"
The translator then only needs to compare the previous and the current
msgid ("too many arguments" and "too few arguments"), and infer which
parts of the translation she needs to change."
In our example,
msgid "Hello, world!"
msgid[ru] "Здравствуй, мир!"
msgstr "Chào thế giới !"
can become
#, fuzzy
#| msgid "Hello, world!"
msgid "Hello, the entire world!"
msgid[ru] "Здравствуй, мир!"
msgstr "Chào thế giới !"
or
#, fuzzy
#| msgid[ru] "Здравствуй, мир!"
msgid "Hello, world!"
msgid[ru] "Здравствулте, мир!"
msgstr "Chào thế giới !"
> msginit would be a good way to initialise a file such as this by
> allowing you to specify the .po and language code any number of time
>
> msgmerge would also need to be updated so that you can update a PO
> file's [xx] entries as well as its source entries.
Yes.
Bruno
Re: translating via an intermediate language
Eddy Petrișor wrote: > > In our example, > > > > msgid "Hello, world!" > > msgid[ru] "Здравствуй, мир!" > > msgstr "Chào thế giới !" > > > > can become > > > > #, fuzzy > > #| msgid "Hello, world!" > > msgid "Hello, the entire world!" > > msgid[ru] "Здравствуй, мир!" > > msgstr "Chào thế giới !" > > > > or > > > > #, fuzzy > > #| msgid[ru] "Здравствуй, мир!" > > msgid "Hello, world!" > > msgid[ru] "Здравствулте, мир!" > > msgstr "Chào thế giới !" > > Why not keep both previous msgids? If both msgid and msgid[ru] have changed, sure both will be moved to the #| section. Bruno
Re: [Translation-i18n] translating via an intermediate language
Dwayne Bailey wrote: > > I can reduce the number of plural forms to 2, by choosing for the > > "singular" the one with n = 1 and for "plural" the one which is chosen > > most often for n -> ∞. > > Would it not be a better options to have > > msgid[0][ru] > msgid[1][ru] > etc > > So that the proper plurals are indeed there? I think that would be redundant. > The same > mechanism could be used to store previous msgstr for review purposes. Hmm, I'm not sure. I think an msgdiff program would be better for review purposes. Bruno
Re: [Translation-i18n] translating via an intermediate language
Clytie Siddall wrote:
> > The translator then only needs to compare the previous and the current
> > msgid ("too many arguments" and "too few arguments"), and infer which
> > parts of the translation she needs to change."
>
> This is great. :)
>
> Thanks, Bruno!
>
> Now I just need to talk my friendly translation editor developer into
> wdiffing the strings and highlighting the differences. ;)
Yes, please do that!
On my side, for people using a terminal with color capabilities, I will
add a "mgscat --color" option that does the same thing, wdiffing the
strings and highlighting the differences. But this will be for after
0.15.1.
Bruno
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tool for translating via an intermediate language
Hello Amos, > You can download it: > http://www.runasimipi.org/instrans.zip > > See the documentation for the scipt at: > http://www.runasimipi.org/instrans-en.html Thank you for making this available. Yesterday I looked at it, but am a bit confused about the purpose of some features, and therefore whether I should consider putting these features into GNU gettext. The current plan is to use a syntax like msgid "English" msgid[es] "Spanish" msgstr "Translation" Thus no need to use a separator, no need for --replace. - --msgstr: "Insert the translated phrases en the msgstrs which are empty." This sounds to be useful for dialects, but the usual way of working with dialects is that the user has several entries in the LANGUAGE variable, e.g. LANGUAGE="de_CH:de". - What's the purpose of --comment versus --bilingual? - Is --statusbar something of general interest? - Can't --search and --recursive be done by the use of a compendium? - What's the purpose of --strip? Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Translation-i18n] Different translations for a single string in debian installer
Hello,
Clytie Siddall wrote:
> msgctxt is a formal context field, e.g.
>
> msgctxt "This is a button: keep it short"
> msgid "Convert"
> msgstr "Đổi"
>
> It's an innovation we've needed badly for a long time, but until
> enough people and servers are running gettext 0.15, we can't use it. :(
>
> Bruno, where does one find info on msgctxt in gettext-0.15? "msgctxt
> --help" doesn't respond.
You find the documentation in the GNU gettext manual ("info msgfmt", up, up,
or "firefox gettext_toc.html") in section "Contexts"/"Using contexts for
solving ambiguities".
The example
msgctxt "This is a button: keep it short"
is not good because that is a typical comment from the programmer to the
translator, and should better be given like this:
#. TRANSLATORS: This is a button: keep it short
A better example is therefore:
#. TRANSLATORS: This is a button: keep it short
msgctxt "OperationDialog"
msgid "Convert"
msgstr "Đổi"
The same PO file can also have
msgctxt "Menu>Tools"
msgid "Convert"
msgstr ""
Bruno
Re: Announce of the upcoming NMU for the isoqlog package
Hello, Christian Perrier wrote: > > Dear maintainer of isoqlog and Debian translators, > ... > If you did any of the, currently incomplete, translations you will get a > copy of this announcement BCCd to you. Please review the translation. I was BCCed because the de.po file contains this: "Project-Id-Version: iso_639 CVS\n" ... "Last-Translator: Bruno Haible <[EMAIL PROTECTED]>\n" But I am not and was never a translator for the isoqlog package. I'm only a translator for the iso_639 domain. The German translator for isoqlog must be someone else. What happened? 1) Someone has apparently merged parts of iso_639.pot into the isoqlog.pot file. This is a *bad* thing, because it causes translators to do duplicated work. The iso_639 domain was created for the very purpose of _sharing_ the translations. Not for having a pool of translations that you can copy/import! (Here I'm speaking as the GNU gettext maintainer.) The fix is: Please use the original iso_639 domain, and change your program to use the 'dgettext' function instead of the 'gettext' function for this domain. Then remove the iso_639 messages from the isoqlog package. 2) In the merge of German PO files, my name was put there instead of the one who translated the "MTA log type:" message. Please find out who was this original translator and put him back. Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announce of the upcoming NMU for the isoqlog package
Christian Perrier wrote:
> > 1) Someone has apparently merged parts of iso_639.pot into the isoqlog.pot
> >file. This is a *bad* thing, because it causes translators to do
> > duplicated
>
>
> I don't think that this is what happened. More likely did the german
> translator use something like:
>
> msgcat --use-first iso_639_de.po de.po >de-new.po
Something like this, yes. But first, he must have downloaded a POT file
containing translation requests like this:
msgid "French"
msgstr ""
Actually I find such a POT file in
http://i18n.debian.net/material/po/unstable/main/i/isoqlog/debian/po/isoqlog_2.2-0.3_templates.pot.gz
> >The fix is: Please use the original iso_639 domain, and change your
> >program to use the 'dgettext' function instead of the 'gettext' function
> >for this domain. Then remove the iso_639 messages from the isoqlog
> > package.
>
> So far, this is not easily achievable because of the nature of Debian
> debconf templates translation method.
You know better than me what "templates" are and how they are processed.
If using dgettext is not an option, you can also do it by PO and POT file
manipulations.
Distinguish
isoqlog_templates-all.pot - the file containing all messages - and
isoqlog_templates-spc.pot - the file containing only the messages
specific to isoqlog.
You know how to generate isoqlog_templates-all.pot - that is what you
currently generate.
For a translator, it's better to see only isoqlog_templates-spc.pot.
So, you can convert isoqlog_templates-all.pot into isoqlog_templates-spc.pot,
like this:
xgettext -o isoqlog_templates-spc.pot \
-x iso_639.pot isoqlog_templates-all.pot
You send this out to the translators. What comes back from the translator,
is, say, isoqlog_templates-spc-${lang}.po. From the iso-639 package you
also have a iso_639-${lang}.po. You combine and merge them like this:
msgmerge -o isoqlog_templates-all-${lang}.po \
-C iso_639-${lang}.po isoqlog_templates-spc-${lang}.po \
isoqlog_templates-all.pot
or like this:
msgcat --use-first -o temp.po isoqlog_templates-spc-${lang}.po
iso_639-${lang}.po
msgmerge -o isoqlog_templates-all-${lang}.po \
temp.po isoqlog_templates-all.pot
This gives you the complete isoqlog_templates-all-${lang}.po, without having
to bother the translators about retranslation.
Put this into your Makefile, and the problem is solved.
Bruno
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Announce of the upcoming NMU for the isoqlog package
Jens Seidel wrote: > You still have a lot to do, only 4% are translated: 358t;3827f;3417u This is a mistaken perception: The iso-639-3 (note the -3 !) file contains lots of proper names which are the same in English and German. "Lingala", "Matengo" and many others are just the same in both languages. The translator can keep these untranslated. Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iso-codes
Clytie Siddall wrote: > I'm a little confused about which file is "iso-639-3". I translate > the iso-codes package for Debian and the TP, and it doesn't list such > a file. The listing (ver. 0.55) is: > > iso_3166 country names 410 strings > iso_3166_2state/province names3856 strings > iso_4217 currency names 265 strings > iso_639 language names 484 strings > > iso_3166_2 is usually only partially-translated, since very few > languages have equivalents for all the state/province names in the > world. > > Which file is "iso-639-3", and where do I find it to translate it? Alastair McKinstry can give you the real answer. Maybe this PO file was only in the Debian iso-codes and not imported into the TP (precisely because there's often nothing to translate), or something like that? I don't remember it. Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iso-codes
Alastair McKinstry wrote: > whats the best way for gettext to handle strings that are unlikely to be > translated / need to be translated? These files contain lots of such > strings, that the translator will probably review and decide do not > need translating. Two solutions come to mind: > - tools fill in the English version. Messy, as it bloats the .mo files, > but allows easy monitoring of new strings when the file changes > - add a new comment: > # ,reviewed > etc. for tools to recognise that this string is deliberately left empty. Indeed this is a case where the PO file format is not optimal. If the POT file doesn't change over time, the translator could be satisfied with simply using "msgmerge --no-fuzzy-matching". But all POT files change over time... I'd recommend to use the English translation explicitly. The "msgen" program does this. Don't care about the size of the .mo file, it's mmaped into memory at runtime, which means the number of strings fetched from the .mo file determines how long it takes, not the file size. If the size really matters, one could add an option to msgfmt to discard the identical mappings. I don't have the intention to add a "#, reviewed" flag. We already have "#, fuzzy", and having both would be confusing for most translators. Bruno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
