Kaixo! On Fri, Jan 14, 2005 at 09:39:46PM +0100, Danilo Šegan wrote: > > Yes, it would; but please, use the already existing convention > > used in KDE instead of reinventing the wheel! > > This is implemented in glib: if you don't like that behaviour, you > should probably report it as a bug/RFE. I think indeed that it would be better if a common marking could be settled (just like having a common format for *.desktop files has huge advantages). Was that implemented long ago? is it still time to change it? > In Gnome project, we commonly rely on updates to > GNU gettext instead of introducing hacks in PO messages themselves Well, in this case, gettext still doesn't provide that (a glib function implementing it is as much a hack in PO message than a libqtsomething implementing it) > (look at how KDE handles ngettext-style features). I indeed prefer it the ngettext way, as it relies on a lower level (and so, larger) base. But in the case of the context information/disambiguation, there isn't any gettext-level solution; and existing solutions all work the same: adding an extra text with some sort of delimiter and stripping at display time what is before the delimiter. The bad thing is there is no standardization at all on the delimiters to use. The advantage of adopting the KDE-style is that it is largely in use, and has been, AFAIK, the first to standardize it on a large scale (for all KDE (and maybe Qt?) programs). On Gnome there was some time ago, ad-hoc solutions when needed, with absolutely no standardization. If something is standardized at glib level it's good news (I thought it was just at gnome level), but I find it unfortunate not to have choose a way similar to an already largely used similar solution. > I myself would prefer if the same processing was done on translation > as is done on original strings, because translators would need no > explanation at all in such cases, and the risk of them mistranslating > it would be minimal (only if they added another context marker, i.e. "|"). > > I.e. translating "file|prefix" to either of "file|blahblah" > (untranslated context), "foo|blahblah" (translated context) or > "blahblah" (without context) would work correctly. I'm interested in > a rationale for choosing current behaviour in glib: You mean that if you translate the context part it is displayed? If so that is indeed a very serious bug! (translators translating it is indeed a very common thing). (and I wonder how that is implemented? it has extra code to differenciate when gettext returns a translation and when it fails to do so? or the stripping of the context is done not on looking just the delimiter but on a byte by byte compareason of all the context string?) > As for choosing "|" over any complicated scheme (like the one used in > KDE): "." works for all the world's email as a way to end DATA input > (and people use dots in email all the time :), so chopping up to first > "|" (inclusive) will work for all the Gnome's software, and it's way > easier to read for translators :) Indeed "|" is simpler, my objection was not about it, but about the fact of having just another divergence while it would be much better to have a common standard. Another possibility would be to have a function with context and translatable string in separate fields actually (and actually that is how KDE does, I have no idea how they generate the *.pot files however), and have *.pot format modified so that those two things go to different fields, in a way similar to what ngettext does; and then try to convince KDE people to modify their *.pot generators so that they produce *.pot files that way. But if it is just to pass to gettext a single string, and parse it to strip context outside of gettext, then aligning with the most used scheme of tagging context would be a big plus, imho. PS: and I'm not even a KDE user myself, I simply can see the benefits in KDE translations of having a consistent, very documented and widely used common way to handle that problem while in Gnome it wasn't really addressed at all, or differently and incoherently by each one. I know when I had needed the feature it wasn't there. It's a good thing it's beeing adressed now; I just wonder why it hasn't been chosen to adopt an existing solution, and instead impose on translators yet another difference to learn (a lot of translators translate both gtk and qt programs) -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Catalan or Esperanto] [min povas skribi en valona, esperanta, angla aux latinidaj lingvoj]
Attachment:
pgpbN93j2FAZd.pgp
Description: PGP signature