Please commit new esperanto translations
Hello, Below is the list of new esperanto translations. I have already sent a notification to this list about the first two ones (gnome-mag and libgtop). People with CVS access can consider this message as a reminder that these files are still pending. Can anyone please commit these files ? Thanks in advance. Release : gnome-2.14 Group : desktop Modules : gnome-mag, libgtop, gnome-session, libwnck Language : Esperanto (eo) The po files can be found at : http://eo-tradukado.tuxfamily.org/deponejo/gnome/gnome-mag/eo.po http://eo-tradukado.tuxfamily.org/deponejo/gnome/libgtop/eo.po http://eo-tradukado.tuxfamily.org/deponejo/gnome/gnome-session/eo.po http://eo-tradukado.tuxfamily.org/deponejo/gnome/libwnck/eo.po Best regards, Guillaume ___ 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
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: Conflicting ChangeLogs
On 04/06/2006, at 3:03 AM, Åsmund Skjæveland wrote: On Sat, Jun 03, 2006 at 04:16:24PM +0930, Clytie Siddall wrote: Speaking of ChangeLogs, I've come across quite a few recently which have needed reconciling: I update the ChangeLog, and CVS tells me it's tried to merge the differences, but is giving up with a headache, so it passes the headache on to me. ;) I don't mind doing this occasionally, but I've had to do it too many times recently. It can take a while, with large differences. I think it's nearly always (or always) been Gnome-2-14 modules' ChangeLogs. Is there any reason why so many ChangeLogs would have major conflicts? If so, is there anything we can do to avoid it? do a cvs update ChangeLog before you add your entry. Don't add your entry until just before you commit your updated PO file. It's a lot less likely that somebody else will update the ChangeLog in the minute it takes you to update the ChangeLog, add your entry, and commit the new ChangeLog and PO files. Åsmund, I _do_ cvs update the ChangeLog just before I need to edit it. The conflict is apparently between my current copy of the ChangeLog and that on the server. It usually occurs when I have checked out the Gnome-2-14 module, then want to update it for the first time. I have no idea why the copy on server become so different in that time, nor why cvs can't integrate those differences. I'll keep a copy next time it happens. Maybe that will help me sort out what is happening. Thanks for your help. :) 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
Yagor, thanks very much for your reply. :) On 06/06/2006, at 5:51 AM, Yavor Doganov wrote: Clytie Siddall wrote: I have a sigh 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
