Re: Translations for LSR project
On 6/7/06, Christian Rose <[EMAIL PROTECTED]> wrote: Speaking of specifiers, a thing I wanted to mention is the following type of messages: #: ../src/LSRMain.py:179 #, python-format msgid "A %s with name %s was removed from profile %s" The second and third specifier should not be a problem here, I think. I assume that they are filled with the name and then the name of the profile, respectively. If you want to help translators with their assumptions, please use translator comments; they would be good to have in either case. Anyway, the problem is the first specifier in this sentence: "A %s with..." It seems like a noun will get inserted there. Please do not insert nouns into sentences with specifiers. I doubt this will even work with English; if the noun was "apple", "A apple with..." would be wrong. The problem gets much worse with other languages that may use different genders for different nouns, and then prefixes or even whole sentences may have to be rewritten depending on the gender of the noun. Please use full sentences instead: "A parameter with name %s was removed from profile %s" "An attribute with name %s was removed from profile %s" "A tag with name %s was removed from profile %s" etc. I have added this as http://bugzilla.gnome.org/show_bug.cgi?id=344471 now. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
Yagor, thanks very much for your reply. :) On 06/06/2006, at 5:51 AM, Yavor Doganov wrote: Clytie Siddall wrote: I have a licensing question. How does such a statement affect those of us who have already assigned our translation copyright to the FSF (for example, translators who contribute to The Translation Project)? This is not a problem, IMHO. The copyright assignment papers that we've signed to FSF refer to the translations which we are willing to assign copyright to the FSF. For me, this is every single translation I make, For me, too. but it totally depends on you. Also note that the Disclaimer of the TP is *not* actually a copyright assignment, e.g. the FSF does not act as assignee. For that you need to write to [EMAIL PROTECTED] I'm considering this is a good idea, because imagine the following scenario, which in fact actually happens sometimes: The copyright holders of Foobar decide to relicense the program from GPL to BSD-like license. Someone takes the BSD code and makes a derived proprietary version. In order to include my translation, they'll have to ask approval from the FSF, which won't be given (in fact it won't be given to relisence it to BSD at first instance). So, it better protects our work and ensures that it will never enhance non-free software. Unfortunately, people sometimes change their mind about freedom. Thankyou very much for clarifying that for me. I really don't understand the legal aspects, and just want my translations to be free. I'm very glad I signed the FSF disclaimer. :) from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
On 6/7/06, Peter Parente <[EMAIL PROTECTED]> wrote: I just noticed Christrian contributed a partial sv.po translation. Thanks! One thing I should point out is that some of the strings in the template have %s in them indicating the will be filled with some value at run time. These %s must also appear in the translated string otherwise Python will throw an exception when it tries to fill in the runtime value. The reason for having the %s in the string is to allow the translator to decide where the template word should appear in their respective language. For instance, the slot in "A device with name %s failed to load" might need to appear in a different position in a different language for it to make sense. Is this a familiar concept for translators? If not, I'll add a note about it to our README.translators file. Yes, it is a most familiar concept. It's the same thing with *printf()-based messages in languages like C or C++. xgettext should automatically detect these specifiers in gettextisized strings and automatically mark the affected messages with the keyword "python-format". This means that later in the process when msgfmt is invoked, msgfmt will check whether the number of %s in the original msgid and the translated msgstr is equal for those messages, and issue an error if not. This of course does not apply if the message is untranslated or fuzzy-marked, then the message is counted as not being translated and such checks are not performed. Translators are instructed to always validate their po files with msgfmt before committing, so this type of problem should be caught before committing, assuming the messages have been properly marked with python-format of course. If you find instances where a string is using %s or a similar specifier and is not being marked with python-format, then it is a real problem. Speaking of specifiers, a thing I wanted to mention is the following type of messages: #: ../src/LSRMain.py:179 #, python-format msgid "A %s with name %s was removed from profile %s" The second and third specifier should not be a problem here, I think. I assume that they are filled with the name and then the name of the profile, respectively. If you want to help translators with their assumptions, please use translator comments; they would be good to have in either case. Anyway, the problem is the first specifier in this sentence: "A %s with..." It seems like a noun will get inserted there. Please do not insert nouns into sentences with specifiers. I doubt this will even work with English; if the noun was "apple", "A apple with..." would be wrong. The problem gets much worse with other languages that may use different genders for different nouns, and then prefixes or even whole sentences may have to be rewritten depending on the gender of the noun. Please use full sentences instead: "A parameter with name %s was removed from profile %s" "An attribute with name %s was removed from profile %s" "A tag with name %s was removed from profile %s" etc. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
I just noticed Christrian contributed a partial sv.po translation. Thanks! One thing I should point out is that some of the strings in the template have %s in them indicating the will be filled with some value at run time. These %s must also appear in the translated string otherwise Python will throw an exception when it tries to fill in the runtime value. The reason for having the %s in the string is to allow the translator to decide where the template word should appear in their respective language. For instance, the slot in "A device with name %s failed to load" might need to appear in a different position in a different language for it to make sense. Is this a familiar concept for translators? If not, I'll add a note about it to our README.translators file. Pete ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
Furthermore, I think it's safe to remove the en_US.po file from CVS -- in GNOME, we require the source messages to be in US English, so there should be no need for an en_US.po anyway. It's only there to test if our install process properly installs the translation. As soon as the first real translation shows up, I'll remove it. I have added lsr to the 'extras' section of the GNOME translation status pages now at http://l10n-status.gnome.org/ -- it should show up in short. Hopefully this will result in some new translations being produced and committed. :-) Great! Thank you. Regarding the license issue -- Perhaps you can add a README.translators file in the po directory where you mention that you would like a proper license clarification at the top of every contributed po file. Good idea. Adding it right now. Thanks for all your help, Pete ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
Clytie Siddall wrote: > > I have a licensing question. How does such a statement affect > those of us who have already assigned our translation copyright to > the FSF (for example, translators who contribute to The Translation > Project)? This is not a problem, IMHO. The copyright assignment papers that we've signed to FSF refer to the translations which we are willing to assign copyright to the FSF. For me, this is every single translation I make, but it totally depends on you. Also note that the Disclaimer of the TP is *not* actually a copyright assignment, e.g. the FSF does not act as assignee. For that you need to write to [EMAIL PROTECTED] I'm considering this is a good idea, because imagine the following scenario, which in fact actually happens sometimes: The copyright holders of Foobar decide to relicense the program from GPL to BSD-like license. Someone takes the BSD code and makes a derived proprietary version. In order to include my translation, they'll have to ask approval from the FSF, which won't be given (in fact it won't be given to relisence it to BSD at first instance). So, it better protects our work and ensures that it will never enhance non-free software. Unfortunately, people sometimes change their mind about freedom. -- "Every non-free program has a lord, a master -- and if you use the program, he is your master." --RMS ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
On 6/2/06, Peter Parente <[EMAIL PROTECTED]> wrote: > Your build tools shouldn't touch the po files -- in GNOME, the > translators update their po files themselves using intltool-update. > This reduces the likelyhood of CVS conflicts and the like when a > translator might spend days or weeks updating a translation. So it > would help if you could treat the po files themselves as the domains > of translators. > The build tools should, however, of course produce the mo files and do > XML merging using intltool if necessary. Sure. Producing the mo files and doing the merging is all I meant. > Other files in the po directory, like POTFILES.in or POTFILES.skip, is > the responsibility of the programmer's to maintain. This is because a > programmer which is involved with the development of the project would > most certainly know which source files are actually used and which are > not, whereas J. Random Translator would not. Fortunately, > "intltool-update --maintain" makes finding stray files which have not > been enlisted easy. Not a problem. I did not know about intltool-update. I will take advantage of that from now on. Cool. It seems intltool-update currently complains on some files in CVS not being enlisted, perhaps you can take a look at that. Furthermore, I think it's safe to remove the en_US.po file from CVS -- in GNOME, we require the source messages to be in US English, so there should be no need for an en_US.po anyway. I have added lsr to the 'extras' section of the GNOME translation status pages now at http://l10n-status.gnome.org/ -- it should show up in short. Hopefully this will result in some new translations being produced and committed. :-) Regarding the license issue -- Perhaps you can add a README.translators file in the po directory where you mention that you would like a proper license clarification at the top of every contributed po file. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
I have a licensing question. How does such a statement affect those of us who have already assigned our translation copyright to the FSF (for example, translators who contribute to The Translation Project)? Sigh is right. I have no idea because IANAL. I believe what we'd like to do is to *ask* translators to put their translations under the CPL used by the project. But if you *want* to use then so be it. It's your translation and I don't want to stave off potential translators because of licensing requirements. If it ever becomes a problem, we'll just have to remove the non-CPL translations until we find a new solution. Pete from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
On 02/06/2006, at 10:12 PM, Peter Parente wrote: Not a problem. I did not know about intltool-update. I will take advantage of that from now on. We do not have a general copyright assignment procedure in the GTP, so AFAIUI technically the translations belong to the translator who contributed it, if nothing else is stated, and under what license terms I do not know. But IANAL of course. If you want to play safe, you can request that all contributed translations properly say "This file is distributed under the same license as the LSR package." in their header, and ask for the translations to be removed if not. OK. I will check on what my employer requires for the translation licenses. If they do wish that notice to be included at the top of all translation files, to where should I post that request? To this mailing list? To some file in CVS that translators read? AFAIK, all you need to do is make sure your POT file contains that line: # This file is distributed under the same license as the LSR package in the header. I've worked on files which already contain such a line, so evidently they can be generated. (See the gettext manual? Or perhaps there is an intltool option.) I have a licensing question. How does such a statement affect those of us who have already assigned our translation copyright to the FSF (for example, translators who contribute to The Translation Project)? from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
Your build tools shouldn't touch the po files -- in GNOME, the translators update their po files themselves using intltool-update. This reduces the likelyhood of CVS conflicts and the like when a translator might spend days or weeks updating a translation. So it would help if you could treat the po files themselves as the domains of translators. The build tools should, however, of course produce the mo files and do XML merging using intltool if necessary. Sure. Producing the mo files and doing the merging is all I meant. Other files in the po directory, like POTFILES.in or POTFILES.skip, is the responsibility of the programmer's to maintain. This is because a programmer which is involved with the development of the project would most certainly know which source files are actually used and which are not, whereas J. Random Translator would not. Fortunately, "intltool-update --maintain" makes finding stray files which have not been enlisted easy. Not a problem. I did not know about intltool-update. I will take advantage of that from now on. We do not have a general copyright assignment procedure in the GTP, so AFAIUI technically the translations belong to the translator who contributed it, if nothing else is stated, and under what license terms I do not know. But IANAL of course. If you want to play safe, you can request that all contributed translations properly say "This file is distributed under the same license as the LSR package." in their header, and ask for the translations to be removed if not. OK. I will check on what my employer requires for the translation licenses. If they do wish that notice to be included at the top of all translation files, to where should I post that request? To this mailing list? To some file in CVS that translators read? Pete ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
On 6/1/06, Peter Parente <[EMAIL PROTECTED]> wrote: Lucky day. intltool-update --pot works fine. In fact, it actually appears to do a better job than pygettext. I was not aware of this improvement. Great! We already know that msginit works to generate language specific files and have our install process setup properly to build po's and install them as mo's. (At least it works with the dummy en_US.po translation we provide.) Your build tools shouldn't touch the po files -- in GNOME, the translators update their po files themselves using intltool-update. This reduces the likelyhood of CVS conflicts and the like when a translator might spend days or weeks updating a translation. So it would help if you could treat the po files themselves as the domains of translators. The build tools should, however, of course produce the mo files and do XML merging using intltool if necessary. Other files in the po directory, like POTFILES.in or POTFILES.skip, is the responsibility of the programmer's to maintain. This is because a programmer which is involved with the development of the project would most certainly know which source files are actually used and which are not, whereas J. Random Translator would not. Fortunately, "intltool-update --maintain" makes finding stray files which have not been enlisted easy. I will go through the rest of i18n guide you sent me and make sure all other requirements are met. I do have one question. The license on LSR is the Common Public License. It is an approved OSI license (http://www.opensource.org/licenses/cpl1.0.php) but it isn't the GPL. Is this a problem? How does licensing work for translations? Do they inherit the license of the project or does gnome require the translations to be GPL? We do not have a general copyright assignment procedure in the GTP, so AFAIUI technically the translations belong to the translator who contributed it, if nothing else is stated, and under what license terms I do not know. But IANAL of course. If you want to play safe, you can request that all contributed translations properly say "This file is distributed under the same license as the LSR package." in their header, and ask for the translations to be removed if not. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
Lucky day. intltool-update --pot works fine. In fact, it actually appears to do a better job than pygettext. I was not aware of this improvement. We already know that msginit works to generate language specific files and have our install process setup properly to build po's and install them as mo's. (At least it works with the dummy en_US.po translation we provide.) I will go through the rest of i18n guide you sent me and make sure all other requirements are met. I do have one question. The license on LSR is the Common Public License. It is an approved OSI license (http://www.opensource.org/licenses/cpl1.0.php) but it isn't the GPL. Is this a problem? How does licensing work for translations? Do they inherit the license of the project or does gnome require the translations to be GPL? Thanks, Pete On 6/1/06, Christian Rose <[EMAIL PROTECTED]> wrote: On 6/1/06, Peter Parente <[EMAIL PROTECTED]> wrote: > Thanks for the info. We can definitely look at how well the standard > intltool-update --pot commands works as compared with pygettext.py. My > guess is that intltool misses Python multiline strings, but we don't > have any of those that are translatable anyways. > > If I get the standard tools working with LSR, should I just email the > list again? Yes, please. As soon as LSR is compatible with the standard tools, we'd love to list it in the translation status pages so that translators can start translating it and track the status of their translations. Furthermore, if you have any questions for getting the standard tools to work, I'm sure there are some people on this list that can help. However, if the questions are very specific to implementation details or bugs in intltool itself, perhaps the intltool mailing list on freedesktop.org is a better choice. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
On Thu, 2006-06-01 at 13:57 -0400, Peter Parente wrote: > > Extended fonts looks ugly, because the HTML is Latin1, while > > the server is saying it is utf-8. Not good for an i18n page :-/ > > > > It may be solved using recode or iconv. > > > > I'm ccing to Malcolm. > > Are you talking about the LSR wiki page which MoinMoin renders? Or the > i18n tutorial? About the tutorial written by Malcolm. -- Germán Poó-Caamaño http://www.ubiobio.cl/~gpoo/ Concepción - Chile ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
On 6/1/06, Peter Parente <[EMAIL PROTECTED]> wrote: Thanks for the info. We can definitely look at how well the standard intltool-update --pot commands works as compared with pygettext.py. My guess is that intltool misses Python multiline strings, but we don't have any of those that are translatable anyways. If I get the standard tools working with LSR, should I just email the list again? Yes, please. As soon as LSR is compatible with the standard tools, we'd love to list it in the translation status pages so that translators can start translating it and track the status of their translations. Furthermore, if you have any questions for getting the standard tools to work, I'm sure there are some people on this list that can help. However, if the questions are very specific to implementation details or bugs in intltool itself, perhaps the intltool mailing list on freedesktop.org is a better choice. Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
Extended fonts looks ugly, because the HTML is Latin1, while the server is saying it is utf-8. Not good for an i18n page :-/ It may be solved using recode or iconv. I'm ccing to Malcolm. Are you talking about the LSR wiki page which MoinMoin renders? Or the i18n tutorial? Pete ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
Thanks for the info. We can definitely look at how well the standard intltool-update --pot commands works as compared with pygettext.py. My guess is that intltool misses Python multiline strings, but we don't have any of those that are translatable anyways. If I get the standard tools working with LSR, should I just email the list again? Pete On 6/1/06, Christian Rose <[EMAIL PROTECTED]> wrote: On 6/1/06, Peter Parente <[EMAIL PROTECTED]> wrote: > We've recently imported a new project called Linux Screen Reader > (http://live.gnome.org/LSR) into cvs.gnome.org. The code is set up to > support internationalization using autotools. I was informed that > gnome.org has a team of translators that can provide localized strings > for any project on request. I think that's great and would love to > have LSR localized. > > The LSR code is in Python which means use of the pygettext.py script > is preferred over the standard gettext program. We have automated the > use of pygettext.py and the generation of POTFILES.in using a script > in our CVS module. We have documentation on how to use this script at > http://live.gnome.org/LSR/PyautoGuide#i18n. Translation by the GNOME Translation Project requires the use of the gettext and intltool tools, so that for example the pot file can be generated simply using "intltool-update --pot" inside the po directory. Until that succeeds, translation of the module by the GTP is unfortunately a no-starter. These requirements are there not only because our automated online translation status tracking tools assume this behavior in all modules, but also since all written documentation for our many hundreds of translators describe this process. Many of our translators are linguists and not programmers, so any module with a diverging behavior isn't likely to get much attention. For these reasons we unfortunately cannot currently list any module at all which doesn't meet the intltool compatibility requirement. There are many pieces of software in GNOME CVS which are written in Python and which work with intltool just fine, so while I do not know any of the details in this case, it still sounds very strange that the use of Python would require a different tool than gettext. I don't know if the following page can be of any help: http://www.gnome.org/~malcolm/i18n/ Regards, Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
On Thu, 2006-06-01 at 19:44 +0200, Christian Rose wrote: > [...] > I don't know if the following page can be of any help: > http://www.gnome.org/~malcolm/i18n/ Extended fonts looks ugly, because the HTML is Latin1, while the server is saying it is utf-8. Not good for an i18n page :-/ It may be solved using recode or iconv. I'm ccing to Malcolm. Regards, -- Germán Poó-Caamaño http://www.ubiobio.cl/~gpoo/ Concepción - Chile ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Translations for LSR project
On 6/1/06, Peter Parente <[EMAIL PROTECTED]> wrote: We've recently imported a new project called Linux Screen Reader (http://live.gnome.org/LSR) into cvs.gnome.org. The code is set up to support internationalization using autotools. I was informed that gnome.org has a team of translators that can provide localized strings for any project on request. I think that's great and would love to have LSR localized. The LSR code is in Python which means use of the pygettext.py script is preferred over the standard gettext program. We have automated the use of pygettext.py and the generation of POTFILES.in using a script in our CVS module. We have documentation on how to use this script at http://live.gnome.org/LSR/PyautoGuide#i18n. Translation by the GNOME Translation Project requires the use of the gettext and intltool tools, so that for example the pot file can be generated simply using "intltool-update --pot" inside the po directory. Until that succeeds, translation of the module by the GTP is unfortunately a no-starter. These requirements are there not only because our automated online translation status tracking tools assume this behavior in all modules, but also since all written documentation for our many hundreds of translators describe this process. Many of our translators are linguists and not programmers, so any module with a diverging behavior isn't likely to get much attention. For these reasons we unfortunately cannot currently list any module at all which doesn't meet the intltool compatibility requirement. There are many pieces of software in GNOME CVS which are written in Python and which work with intltool just fine, so while I do not know any of the details in this case, it still sounds very strange that the use of Python would require a different tool than gettext. I don't know if the following page can be of any help: http://www.gnome.org/~malcolm/i18n/ Regards, Christian ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Translations for LSR project
Hi, We've recently imported a new project called Linux Screen Reader (http://live.gnome.org/LSR) into cvs.gnome.org. The code is set up to support internationalization using autotools. I was informed that gnome.org has a team of translators that can provide localized strings for any project on request. I think that's great and would love to have LSR localized. The LSR code is in Python which means use of the pygettext.py script is preferred over the standard gettext program. We have automated the use of pygettext.py and the generation of POTFILES.in using a script in our CVS module. We have documentation on how to use this script at http://live.gnome.org/LSR/PyautoGuide#i18n. I'm not sure what the right procedure here is for getting started. Please let me know if you need more information from me or have your own checklist you would like me to follow to make your job easier. Thanks in advance, Pete ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
