Thomas,
A good idea and a pet peeve of mine. I hope that you don't mind if I add a few issyes:: A) multiple strings with very few changes: typically different case of the first letter, or a full stop "." at the end of one of them. B) Duplications: phonetic alphabet, GPL notice, etc C) Markup: developers should handle it internally if it's not a problem for any language. stuff like <i>my string</i> should be just "my string". D) Localised integers: for some languages, locales determine the way numbers or writtern. There are two sets, Arabic and Hindu. It is possible to make them localisable if: 1) every integer (%d) that is displayed in a UI should be offered for translations. So translators like us can do (%Id). This is important for consistency. 2) Make gettext handle langauges and systems (like Solaris) that don't understand (%Id) gracefully. See [1] for example. Now before expanding on these points, allow me to quote your suggestions: في ح، 02-12-2007 عند 15:11 -0500 ، كتب Thomas Thurman: > So: > > 1) It would have saved trouble had the system been designed like this > originally, wouldn't it? You mean gettext? that would be good. But isn't it difficult for it to know which strings are static? (like your example above). Should it go by the quotes? > > 2) If so, should we change existing lines so that they work this way, > given that they will both cause existing translations to vanish but > also reduce the msgid count in translation files? > Oh please yes :-) > 3) If so, should we have some kind of GNOME Goal to identify and > eliminate such lines? > Oh yeah again. Now comes an expansion on these points and mine. Point A is a variation of your point. Point C and D need clear GNOME policies. I'm not sure how I can suggest that or if I have the community momentum to suggest them. So any input is welcome :) For point B, I have been thinking of a way to try to help translators with consistency. Currently we have a few important packages (Like gtk +-*) with strings that happen over and over in packages. We also have the gnome glossary which is not used and is there just to aid translator tools. These two still don't address the problem of maintaining consistency in a large number of applications. Wouldn't it be nice to have a dedicated gnome l10n package that serves to assemble the terms that occur all over gnome packages? We can easily also use some stat building scripts to get the strings that occur over and over. Djihed > T > _______________________________________________ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n -- Have a project you would like to be translated to Arabic? Let us know: http://wiki.arabeyes.org/Translation_requests Blog: http://djihed.com _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
