Re: please commit these translation
Le dimanche 31 octobre 2010 à 10:14 +0800, Umarzuki Mochlis a écrit : Hi, Can anyone with git access help commit these: http://l10n.gnome.org/vertimus/nautilus/master/po/ms http://l10n.gnome.org/vertimus/gnome-screensaver/master/po/ms http://l10n.gnome.org/vertimus/592/545/74 Done. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GNOME translation project
Dear developers, I would like to remind you that your project should be translated using the GNOME translation project in order to be coherent with the other translation of the GNOME project. Therefore when you receive some translated PO files by someone, you should submit this files to the appropriate team for the translation to be approved. See Olivier Le Thanh Duong translations for pdfmod : http://git.gnome.org/browse/pdfmod/log/?qt=grepq=french See Thierry Saliou alias Teza translations for mistelix : http://git.gnome.org/browse/mistelix/log/?qt=grepq=french Sincerely Bruno Brouard Coordinator of the GNOME French Team ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translating schema files (was: Re: Survey results (yay!))
El mar, 02-11-2010 a las 12:09 +0200, li...@kambanaria.org escribió: Just to suggest an idea: The predominant message thus far has been Developers you should do more work, so that we can translate less of your application. Perhaps we can improve it a bit. Speaking as a member of a supported language: The style of the translation of strings is different depending on the place they appear. - Interface strings demand maximum clarity in minimum characters. Additionally in testing - you can change them to improve the layout of the windows, menus, etc. Plus you need to check keyboard shortcuts. - With schema messages you translate to explain things, so you can really write sentences and paragraphs to be sure that the user understands the gconf key meaning. - Console messages have demands on their own. On the one hand they can be reformatted to fit the most usual terminal size (for example width of 80 chars). On the other hand a team can decide to use a more limited character set for console messages (for example the whole range of UTF-8 characters for interface, limited subset known to work in terminals, or fitting popular for the locale 8bit charsets). Well, sometimes it's impossible to fit your translation in 80 characters, especially when the original message is already quite long. But never mind. So explaining the different types of messages has *strong* benefits for teams that intend to translate the strings. The messages are not being singled out for negligence. Providing the type will improve the translation and review. Please note that I am using the term console messages - those that appear on the command line. I do not think the term error message used in the discussion thus far had a clear enough definition - I do think people wrote about different issues. Perhaps this could be included in the translation software, I don't think it's difficult to create a plugin for gtranslator which marks certain strings in a different way (colors, whatever...); however I'm not a hacker myself. Regards. -- Jorge González González alor...@gmail.com Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
RFC: Keyboard shortcuts, ways to improve
Hi, Is there a way we can automate checks of translation of keyboard shortcuts? This is an extremely tedious and error prone task with the current methodology. Translation tools state whether a keyboard shortcut is present in the translation or not. This is not enough because there can be many collisions between the accelerators. So we revert to manually trying to open every windows and screen, which we sometimes we cannot do (mostly because we do not know how). What I ideally hope for is a tool that can do the following: 1. Start the application in the new locale. 2. Have some way to open all dialogs and windows. 3. Check the accelerators. I fancy that [3] is doable with the accessibility framework - labels and messages in the interface should be enumerable and readable somehow, so shortcuts can be checked for collisions (and others). [2] is doable with the assistance of some testing framework (that I also believe exists, that can open windows, simulate mouse clicks and keyboard input. It will require some cooperation from the developers but they will have their own reasons to participate - such user interaction testcases are nice to have when developing, plus they could catch some bugs. Plus once several apps start having these, the benefits will prove to developers that it is worth having it. No need to make such testing harness compulsory. Kind regards: al_shopov ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translating schema files (was: Re: Survey results (yay!))
Op Di, 2010-11-02 om 12:09 +0200 skryf li...@kambanaria.org: Just to suggest an idea: The predominant message thus far has been Developers you should do more work, so that we can translate less of your application. Perhaps we can improve it a bit. To be fair, I think several suggestions are about solving this without developer intervention or any changes in their workflow. And it is really about spending the same amount of time on the most meaningful stuff, not less work. I'm sure developers would prefer a UI translation over schemas translation if they had to choose between them. Speaking as a member of a supported language: The style of the translation of strings is different depending on the place they appear. - Interface strings demand maximum clarity in minimum characters. Additionally in testing - you can change them to improve the layout of the windows, menus, etc. Plus you need to check keyboard shortcuts. - With schema messages you translate to explain things, so you can really write sentences and paragraphs to be sure that the user understands the gconf key meaning. - Console messages have demands on their own. On the one hand they can be reformatted to fit the most usual terminal size (for example width of 80 chars). On the other hand a team can decide to use a more limited character set for console messages (for example the whole range of UTF-8 characters for interface, limited subset known to work in terminals, or fitting popular for the locale 8bit charsets). So explaining the different types of messages has *strong* benefits for teams that intend to translate the strings. The messages are not being singled out for negligence. Providing the type will improve the translation and review. Please note that I am using the term console messages - those that appear on the command line. I do not think the term error message used in the discussion thus far had a clear enough definition - I do think people wrote about different issues. I agree that there are other advantages to splitting. For example, if we do integrate some knowledge of this into the build system, we can avoid putting the translations of the schemas into the .mo files, which could reduce their size, making all sorts of people happier, I guess. Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/latest-pootle-news ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New team for Luganda (lg)
Le lundi 01 novembre 2010 à 08:52 +0100, Claude Paroz a écrit : Le samedi 30 octobre 2010 à 22:37 +0100, Kizito Birabwa a écrit : Kizito Birabwa kbira...@yahoo.co.uk Bugzilla account: kbira...@yahoo.co.uk English name: Luganda Native name: Liganda ISO 639 code: lg No mailing list at the moment No web page at the moment Hi Kizito, Glad to see another African language in move! Could you please send me privately a first translated file (even partially) so as I can commit it and initialize your language's statistics? Team page created: http://l10n.gnome.org/teams/lg Happy translating! Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'gnome-disk-utility.master'
Le jeudi 28 octobre 2010 à 00:21 +0200, Andre Klapper a écrit : On Wed, 2010-10-27 at 22:18 +, GNOME Status Pages wrote: This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'gnome-disk-utility.master': + A hard disk is reporting health problems. + Examine + Hard Disk Problems Detected + Multiple hard disks are reporting health problems. + Multiple system hard disks are reporting health problems. your commit 575f884eb645e4ee3699de774b74caab923e4b63 to git master broke the string freeze for GNOME 2.32 as g-d-u does not have a gnome-2-32 branch yet. Friendly ping. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
GCompris needs a translation update
Hi, We have set the 26th of November as the new release date for GCompris. A good opportunity to update the translation if its not already done. There is a special think to do, the new hangman activity uses our src/readingh-activity/resources/wordsgame/default-locale.xml files to propose words to the children. It is thus very important now to have them properly filled with about 1000 to 2000 words. For now I did the work for English and French. Translators, please refer to this page for instructions: http://gcompris.net/wiki/Translation_addons Thanks for your help, -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
