Re: Context in translations, Q_() and gettext
Le samedi 24 novembre 2007 à 22:41 -0500, Matthias Clasen a écrit : As most GNOME packages use intltool to generate/update po files, do you know which minimal version of intltool is required to support/implement this feature? Current version on l10n.gnome.org is: gettext 0.14.5 intltool 0.35.5 From looking at FindPOTKeywords in intltool-update, it appears you can override the keyword options that intltool-update passes to xgettext by setting XGETTEXT_OPTIONS in po/Makevars or XGETTEXT_KEYWORDS in po/Makefile.in.in. So, you should be able to switch to msgctxt by requiring gettext 0.15 and adding XGETTEXT_KEYWORDS=--keyword=_ --keyword=N_ --keyword=Q_:1g --keyword=C_:1c,2 to po/Makefile.in.in Thanks to Olav, we have now gettext 0.16 on l10n.gnome.org. Matthias, can you test this on glib ? Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
+1 Leonardo Fontenelle http://leonardof.org/2007/11/24/hibernate-is-necessary-proprietary-driver-is-not-so-necessary/en/ 2007/11/25, Matthias Clasen [EMAIL PROTECTED]: As most GNOME packages use intltool to generate/update po files, do you know which minimal version of intltool is required to support/implement this feature? Current version on l10n.gnome.org is: gettext 0.14.5 intltool 0.35.5 From looking at FindPOTKeywords in intltool-update, it appears you can override the keyword options that intltool-update passes to xgettext by setting XGETTEXT_OPTIONS in po/Makevars or XGETTEXT_KEYWORDS in po/Makefile.in.in. So, you should be able to switch to msgctxt by requiring gettext 0.15 and adding XGETTEXT_KEYWORDS=--keyword=_ --keyword=N_ --keyword=Q_:1g --keyword=C_:1c,2 to po/Makefile.in.in If the Gnome translators agree that conversion to msgctxt would be a good thing, then this may make a good Gnome Goal. As an aside, I believe that KDE4 is also going to use msgctxt in po files. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
Le samedi 24 novembre 2007 à 00:45 -0500, Matthias Clasen a écrit : Hey, some time has passed since the last discussion of this topic (context in translations), and I have now decided to commit my GLib patch, which adds a 2 argument macro for translations with context. So instead of Q_(context|id) it will soon be possible to write C_(context, id) And, using GNU gettext = 0.15, you will be able to convert both forms into msgctxt context msgid msgid msgstr by calling xgettext --keyword=Q_:1g --keyword=C_:1c,2 As most GNOME packages use intltool to generate/update po files, do you know which minimal version of intltool is required to support/implement this feature? Current version on l10n.gnome.org is: gettext 0.14.5 intltool 0.35.5 Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
As most GNOME packages use intltool to generate/update po files, do you know which minimal version of intltool is required to support/implement this feature? Current version on l10n.gnome.org is: gettext 0.14.5 intltool 0.35.5 From looking at FindPOTKeywords in intltool-update, it appears you can override the keyword options that intltool-update passes to xgettext by setting XGETTEXT_OPTIONS in po/Makevars or XGETTEXT_KEYWORDS in po/Makefile.in.in. So, you should be able to switch to msgctxt by requiring gettext 0.15 and adding XGETTEXT_KEYWORDS=--keyword=_ --keyword=N_ --keyword=Q_:1g --keyword=C_:1c,2 to po/Makefile.in.in If the Gnome translators agree that conversion to msgctxt would be a good thing, then this may make a good Gnome Goal. As an aside, I believe that KDE4 is also going to use msgctxt in po files. Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Context in translations, Q_() and gettext
Hey, some time has passed since the last discussion of this topic (context in translations), and I have now decided to commit my GLib patch, which adds a 2 argument macro for translations with context. So instead of Q_(context|id) it will soon be possible to write C_(context, id) And, using GNU gettext = 0.15, you will be able to convert both forms into msgctxt context msgid msgid msgstr by calling xgettext --keyword=Q_:1g --keyword=C_:1c,2 From a quick search, it appears that at least some translation tools support msgctxt nowadays (kbabel, pootle, translate, launchpad). Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
I'm just lurking on the list and can't really comment on all things, but I'll comment on the wordforge tools. (Pootle, Pootling and the translate toolkit) Op Sondag 08-07-2007 om 22:18 uur [tijdzone -0400], schreef Matthias Clasen: GLib offers the Q_() macro for adding context to translations, but the solution of embedding the context into the msgid is error-prone for translators and can lead to regular msgids being misinterpreted as having a context. When this was last discussed on this list 1 1/2 years ago, there seemed to be consensus that a solution that keeps context and msgid separate is preferable. Since then, GNU gettext has added support for this in the form of msgctxt, which has been available in gettext 0.15 for a year now. I'd like to add support for separate message context to the next GLib release (i.e. not 2.14, which is almost done), in the form of a C_(Context,Msgid) macro. An implementation of this can be found in http://bugzilla.gnome.org/show_bug.cgi?id=142676 . The patch also modifies the Q_() macro so that it can keep working even if the contexts in .po files are converted to msgctxt (xgettext can do this automatically) There is a number of questions that I'd like to find answers for before we decide to push for adoption of msgctxt: - Have the translation tools caught up with msgctxt yet, or will msgctxt cause problems for translators ? Pootle 1.0 and the translate toolkit 1.0 have support for msgctxt. Pootle will display the context in the same way as it handles KDE style msgid comments by displaying it close to the source string. We have not exhaustively tested our merging code and all the tools where the context might play a role, but we do support it in the file format and at least some of the tools. - Will it be a big problem for people using alternative gettext implementations if msgctxt starts to appear in .po files ? Do we need to provide a script to fold back msgctxt into msgid prefixes, for use with old msgfmt implementations, or can we expect everybody to use GNU gettext for creating .mo files ? We already handle it, and some of the tools in the toolkit might just ignore it instead of breaking. It shouldn't normally create big problems, I would say. Our current pocompile (msgfmt equivalent) doesn't handle it yet (it will create .mo files without the context part), but support for it is already committed in SVN and will form part of the next release of the toolkit (1.1). - How can we handle existing translations when context moves from the msgid to msgctxt ? Does msgmerge handle this intelligently, or do we need some conversion script ? The translate toolkit is written in Python, it might easy to write such a conversion script based on our current pot2po tool by just manipulating the data before the normal matching. (pot2po is our equivalent to msgmerge) http://translate.sourceforge.net/wiki/toolkit/pot2po - Can we make the transition from Q_() to C_() smoother ? Unfortunately, xgettext does not provide a way to extract strings from a 2-argument macro like C_() to msgid-prefix form. ... I would suggest that we schedule a bug day where people can try out all the combinations of features and tools that they can think of. This way we might be able to make good progress in a single day and build a base of test files with wide variety. The upcoming release of Pootling (version 0.2) relies on translate toolkit 1.0 and will support msgctxt as well. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
Le dimanche 08 juillet 2007 à 22:18 -0400, Matthias Clasen a écrit : GLib offers the Q_() macro for adding context to translations, but the solution of embedding the context into the msgid is error-prone for translators and can lead to regular msgids being misinterpreted as having a context. When this was last discussed on this list 1 1/2 years ago, there seemed to be consensus that a solution that keeps context and msgid separate is preferable. Since then, GNU gettext has added support for this in the form of msgctxt, which has been available in gettext 0.15 for a year now. I'd like to add support for separate message context to the next GLib release (i.e. not 2.14, which is almost done), in the form of a C_(Context,Msgid) macro. An implementation of this can be found in http://bugzilla.gnome.org/show_bug.cgi?id=142676 . The patch also modifies the Q_() macro so that it can keep working even if the contexts in .po files are converted to msgctxt (xgettext can do this automatically) There is a number of questions that I'd like to find answers for before we decide to push for adoption of msgctxt: - Have the translation tools caught up with msgctxt yet, or will msgctxt cause problems for translators ? Hi Matthias, It's a great idea to implement this new capability. It seems that only KBabel has implemented it, from 1.11, KDE 3.5: http://lxr.kde.org/source/KDE/kdesdk/kbabel/ChangeLog poEdit has a bug report for this: http://sourceforge.net/tracker/index.php?func=detailaid=1680554group_id=27043atid=389153 And I think GTranslator has no support either. I didn't find anything in the ChangeLog: http://svn.gnome.org/viewcvs/gtranslator/trunk/ChangeLog Anyway, KBabel is currently the better maintained tool with the greatest functionnalities. And this is said by a GNOMEr... :-) - Will it be a big problem for people using alternative gettext implementations if msgctxt starts to appear in .po files ? Do we need to provide a script to fold back msgctxt into msgid prefixes, for use with old msgfmt implementations, or can we expect everybody to use GNU gettext for creating .mo files ? I think we should go ahead, and fix alternative gettext implementations, if any. - How can we handle existing translations when context moves from the msgid to msgctxt ? Does msgmerge handle this intelligently, or do we need some conversion script ? Needs some testing. It should at least generate a fuzzy. - Can we make the transition from Q_() to C_() smoother ? Unfortunately, xgettext does not provide a way to extract strings from a 2-argument macro like C_() to msgid-prefix form. As a test balloon for this, I have added support for separate context to the GtkBuilder xml format, in the following form: property name=foo translatable=yes context=contextmessage/property A patch which makes intltool handle this format can be found here http://bugzilla.gnome.org/show_bug.cgi?id=454894. The patch allows intltool to extract this as either pgettext (context, message) or gettext (context|message) GtkBuilder will work with the resulting .mo files for both variants. I find it very clean. But I'm not experienced enough in the programming part to evaluate all possible side effects. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Context in translations, Q_() and gettext
GLib offers the Q_() macro for adding context to translations, but the solution of embedding the context into the msgid is error-prone for translators and can lead to regular msgids being misinterpreted as having a context. When this was last discussed on this list 1 1/2 years ago, there seemed to be consensus that a solution that keeps context and msgid separate is preferable. Since then, GNU gettext has added support for this in the form of msgctxt, which has been available in gettext 0.15 for a year now. I'd like to add support for separate message context to the next GLib release (i.e. not 2.14, which is almost done), in the form of a C_(Context,Msgid) macro. An implementation of this can be found in http://bugzilla.gnome.org/show_bug.cgi?id=142676 . The patch also modifies the Q_() macro so that it can keep working even if the contexts in .po files are converted to msgctxt (xgettext can do this automatically) There is a number of questions that I'd like to find answers for before we decide to push for adoption of msgctxt: - Have the translation tools caught up with msgctxt yet, or will msgctxt cause problems for translators ? - Will it be a big problem for people using alternative gettext implementations if msgctxt starts to appear in .po files ? Do we need to provide a script to fold back msgctxt into msgid prefixes, for use with old msgfmt implementations, or can we expect everybody to use GNU gettext for creating .mo files ? - How can we handle existing translations when context moves from the msgid to msgctxt ? Does msgmerge handle this intelligently, or do we need some conversion script ? - Can we make the transition from Q_() to C_() smoother ? Unfortunately, xgettext does not provide a way to extract strings from a 2-argument macro like C_() to msgid-prefix form. As a test balloon for this, I have added support for separate context to the GtkBuilder xml format, in the following form: property name=foo translatable=yes context=contextmessage/property A patch which makes intltool handle this format can be found here http://bugzilla.gnome.org/show_bug.cgi?id=454894. The patch allows intltool to extract this as either pgettext (context, message) or gettext (context|message) GtkBuilder will work with the resulting .mo files for both variants. Comments ? Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
Hi Mart, On December 22nd, Mart Raudsepp wrote: What about the --keyword=WORD switch in xgettext? Can't Q2_ simply be listed with that? Yes it will be listed with that in Makefiles (and intltool stuff), but gettext introduced a new syntax for it to be possible. Anyway, it can't solve the problem (which is that Q_() used single string with context, and Q2_() expects two separate strings). Those two are incompatible approaches, and Bruno opted for the better long-term solution, rather than going for compatibility with Gnome and former GNU practices/recommendations. :) Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
Matthias Clasen wrote: On 12/21/05, James Henstridge [EMAIL PROTECTED] wrote: . One issue with this change is that current xgettext releases probably won't extract strings for the Q2_() form. Ah, you are right. We would have to do some extrs step, like extractig the Q2 calls and convert them to Q in an auxiliary file, and feed that to xgettext. What about the --keyword=WORD switch in xgettext? Can't Q2_ simply be listed with that? -k, --keyword[=WORD] additional keyword to be looked for (without WORD means not to use default keywords) (only languages C, C++, ObjectiveC, Shell, Python, Lisp, Emac- sLisp, librep, Scheme, Java, C#, awk, Tcl, Perl, PHP, GCC- source, Glade) I recall using this for some kind of a keyword a looong way back, too long to remember for sure. Regards, Mart Raudsepp, who's using Replay All this time, and is only subscribed to gtk-devel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
Will there be a tool to convert .po files from msgid foo|bar to the
new msgctxt stuff? Could msgmerge or whatever do it automatically?
#if HAVE_PGETTEXT
#define Q2_(context,msgid) pgettext(context,msgid)
#else
#define Q2_(context,msgid) Q_(context ## | ## msgid)
#endif
This'd break GDM, which uses a similar syntax to allow the translators
to specify sort order of languages:
Off the top of my head:
A-K|English (US)- A-K|Engelsk (USA)
M-Z|Norwegian Nynorsk - M-Å|Norsk (nynorsk)
--
Åsmund Skjæveland {
[EMAIL PROTECTED]
}
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
Mart Raudsepp wrote: Matthias Clasen wrote: On 12/21/05, James Henstridge [EMAIL PROTECTED] wrote: . One issue with this change is that current xgettext releases probably won't extract strings for the Q2_() form. Ah, you are right. We would have to do some extrs step, like extractig the Q2 calls and convert them to Q in an auxiliary file, and feed that to xgettext. What about the --keyword=WORD switch in xgettext? Can't Q2_ simply be listed with that? -k, --keyword[=WORD] additional keyword to be looked for (without WORD means not to use default keywords) (only languages C, C++, ObjectiveC, Shell, Python, Lisp, Emac- sLisp, librep, Scheme, Java, C#, awk, Tcl, Perl, PHP, GCC- source, Glade) I recall using this for some kind of a keyword a looong way back, too long to remember for sure. The problem is that Q2_() would take two arguments (the context and the message ID), both of which are required to obtain the correct translation. The current xgettext does not know that it needs both. We could do --keyword=Q2_:2 to tell xgettext to treat the second argument as the message ID, but that would miss the context string. James. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
On Thu, 2005-12-22 at 11:02 +0800, James Henstridge wrote: One issue with this change is that current xgettext releases probably won't extract strings for the Q2_() form. How does that work? Does it grep for start of symbol optional single letter underscore optional whitespace parentheses ? Does ngettext() need a shorthand? You use it so infrequently, a short macro is likely to just obfuscate things. Hmm, good point. This is kind of cryptic: http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html We probably need a better explanation of when to use gi18n.h vs. gi18n-lib.h, and what to do about ngettext(). Federico ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
On Wed, 2005-12-21 at 01:07 -0500, Matthias Clasen wrote: I just learned that GNU gettext will soon have official support for disambiguating context in translations. Will there be a tool to convert .po files from msgid foo|bar to the new msgctxt stuff? Could msgmerge or whatever do it automatically? #if HAVE_PGETTEXT #define Q2_(context,msgid) pgettext(context,msgid) #else #define Q2_(context,msgid) Q_(context ## | ## msgid) #endif The name Q2_() is certainly not perfect. Well, at least one can interpret the 2 as a subtle hint that the macro takes 2 arguments... This makes sense. Or we can pick another prefix. Why not C_ for context? [Don't we support ngettext yet?] Federico ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
On Wed, 2005-12-21 at 14:22 -0600, Federico Mena Quintero wrote: On Wed, 2005-12-21 at 01:07 -0500, Matthias Clasen wrote: I just learned that GNU gettext will soon have official support for disambiguating context in translations. Will there be a tool to convert .po files from msgid foo|bar to the new msgctxt stuff? Could msgmerge or whatever do it automatically? I'm not sure if msgmerge will be up to that. But a little bit of sed magic should get us there. That does not have to happen any time soon though, since we probably can't ship msgctxt-containing .po files until the next gettext is widespread, anyway. The important thing to get started soon is the conversion Q_(foo|bar) - Q2_(foo, bar) so that we are done with that when the time is ripe to rely on msgctxt. This makes sense. Or we can pick another prefix. Why not C_ for context? [Don't we support ngettext yet?] glib requires ngettext. We don't define a shorthand macro for that, though, and N_() is already taken for noop... Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
On Wed, 2005-12-21 at 16:01 -0500, Matthias Clasen wrote: The important thing to get started soon is the conversion Q_(foo|bar) - Q2_(foo, bar) so that we are done with that when the time is ripe to rely on msgctxt. Yeah. Fortunately this happens in very few places in GTK+. I don't know about the rest of GNOME. glib requires ngettext. We don't define a shorthand macro for that, though, and N_() is already taken for noop... P_() for plural? :) Federico ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
On Wed, 2005-12-21 at 15:19 -0600, Federico Mena Quintero wrote: On Wed, 2005-12-21 at 16:01 -0500, Matthias Clasen wrote: The important thing to get started soon is the conversion Q_(foo|bar) - Q2_(foo, bar) so that we are done with that when the time is ripe to rely on msgctxt. Yeah. Fortunately this happens in very few places in GTK+. I don't know about the rest of GNOME. glib requires ngettext. We don't define a shorthand macro for that, though, and N_() is already taken for noop... P_() for plural? :) P_() is already used inside GTK+ for property strings (we could change that, but it would be a massive change...) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Context in translations, Q_() and gettext
Federico Mena Quintero wrote: On Wed, 2005-12-21 at 16:01 -0500, Matthias Clasen wrote: The important thing to get started soon is the conversion Q_(foo|bar) - Q2_(foo, bar) so that we are done with that when the time is ripe to rely on msgctxt. Yeah. Fortunately this happens in very few places in GTK+. I don't know about the rest of GNOME. One issue with this change is that current xgettext releases probably won't extract strings for the Q2_() form. glib requires ngettext. We don't define a shorthand macro for that, though, and N_() is already taken for noop... P_() for plural? :) Does ngettext() need a shorthand? You use it so infrequently, a short macro is likely to just obfuscate things. James. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Context in translations, Q_() and gettext
I just learned that GNU gettext will soon have official support for disambiguating context in translations. This is great. However, Bruno decided to not implement the somewhat ad-hoc solution which has been recommended for years in the gettext manual, and implemented in glib using Q_(), which is to embed the context as a prefix in the msgid, separated by |. Instead, gettext will introduce new macros, pgettext (context, msgid) npgettext (context, msgid, msgid_pural, n) and the context will appear in .po files as msgctxt context msgid msgid msgstr ... Translators can hope that tools will learn about this new syntax and support disambiguating context better. Unfortunately, xgettext will only be able to create .po files with the new syntax if the context and the msgid appear as two separate string literals in the source. Which is not the case for Q_(). Therefore, I think we should consider deprecating the single-argument Q_() macro in favor of a Q2_() macro which takes context and msgid as separate arguments. It should be easy to detect the presence of a sufficently new gettext and implement Q2_() by falling back to the Q_() implementation in the absence of pgettext(): #if HAVE_PGETTEXT #define Q2_(context,msgid) pgettext(context,msgid) #else #define Q2_(context,msgid) Q_(context ## | ## msgid) #endif The name Q2_() is certainly not perfect. Well, at least one can interpret the 2 as a subtle hint that the macro takes 2 arguments... What do you think ? Matthias ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
