Re: esperanta tradukado
I implore you to just ignore Launchpad's Ubuntu translations. None of the work done there will ever find its way upstream. I used to be a en_GB translator there, but left after they made some bad decisions, and still didn't upstream anything (I was promised on joining that they would). Bruce, thanks for your suggestion. but after looking I found out that for example gedit seems fully translated to Esperanto in Launchpad: https://translations.launchpad.net/ubuntu/jaunty/+source/gedit/+pots/gedit/eo Of course I can't ignore this work. And It should be brought upstream, of course. So should I just upload this work to http://l10n.gnome.org/vertimus/gedit/master/po/eo (notifying and thanking the authors, perhaps)? (I still don't have direct git commit access) Jacob -- Jacob Nordfalk Venu al la plej granda kultura evento en esperantujo: Kultura Esperanto-Festivalo - la 7a ĝis la 12a de julio 2009 - http://kef.saluton.dk एस्पेरान्तो के हो? http://www.esperanto.org.np/. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: esperanta tradukado
Le dimanche 14 juin 2009 à 02:34 +0200, Jacob Nordfalk a écrit : 2009/6/14 Andre Klapper ak...@gmx.net Am Sonntag, den 14.06.2009, 01:11 +0200 schrieb Jacob Nordfalk: Here's first question: 1) In daily life I actually use Ubuntu (8.10) and the Gnome applications in Esperanto. Most of the apps are actually working fine in Esperanto, but anyway when I look at http://l10n.gnome.org/teams/eo the Esperanto coverace seems down to about 6%. How can that be? Is it becaurse there is some downstream translation going on for Ubuntu? Yes. Ubuntu maintains downstream translations in Launchpad, and it's always a pity when this stuff does not get upstream so all distributions shipping GNOME can receive the benefits of better Esperanto support. OK. Kim and I'll have a look into whether theres something to import from downstream, but it doesent seem so to me: When I look at https://translations.launchpad.net/~gnome-l10n-eo its completely empty. So quetion 2: Is Launchpad just not working properly, or ARE there actually nothing to get downstream for Esperanto? You just didn't look at the right place. Here it is: https://translations.launchpad.net/ubuntu/jaunty/+lang/eo/ Everywhere you see purple color, that means the package contains non-upstreamed translations. Question 3: Looking at http://l10n.gnome.org/languages/eo/ I'm in doubt whether to concentrate on GNOME 2.26 or 2.28. Will changes I commit to 2.26 also go into 2.28 if no original text has changed? Go with 2.28, as Andre told you. Question 4: At http://l10n.gnome.org/vertimus/sound-juicer/master/po/eo it says 0% translated and the master is empty BUT two translations have been submitted by a user. This is not two translations. The first one is the translation uploaded by the user, and the second one is an automatically merged version by the system with the latest POT file. How do I get them the whole way into to the repositiry? By downloading the whole source code by git and then making a patch (after reviewing)? Isnt there an easier way? Downloading source code from Git is only useful if you're pushing the file yourself. The suggested workflow is: - download the *.merged.po file, proofread and complete it if needed. You can use the Reserve for proofreading, Upload the proofread translation, Ready to commit actions to achieve this. - as long as you don't own a Git account, write to this list whenever you have files to commit, either on l10n.gnome.org in the Ready to commit state or in a Bugzilla report, at your convenance. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: esperanta tradukado
Le lundi 15 juin 2009 à 10:18 +0200, Jacob Nordfalk a écrit : I implore you to just ignore Launchpad's Ubuntu translations. None of the work done there will ever find its way upstream. I used to be a en_GB translator there, but left after they made some bad decisions, and still didn't upstream anything (I was promised on joining that they would). Bruce, thanks for your suggestion. but after looking I found out that for example gedit seems fully translated to Esperanto in Launchpad: https://translations.launchpad.net/ubuntu/jaunty/+source/gedit/+pots/gedit/eo Of course I can't ignore this work. And It should be brought upstream, of course. So should I just upload this work to http://l10n.gnome.org/vertimus/gedit/master/po/eo (notifying and thanking the authors, perhaps)? Yes, this is the recommended way to do this. You can then check the *.merged.po file which will reveal differences between the Jaunty gedit pot file and the current development (master) gedit one. Youi can then follow the workflow suggested in my previous mail. Ubuntu translations are now released under the liberal BSD license, this means that you are allowed to upstream them, as far as you keep the original authors credits. Claude ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New GNOME Website - Translation
Hallo Lucas and Jens I have had a look at the proposal. From what I can see it looks fine. What matters to us is that we can maintain the same workflows (fetch, translate, proofread, corrections, upload) that we usually use. From how I understand the proposal it will ultimately become possible to use po-files for everything, so in that case it's all flowers and sunshine. I do however have a couple of questions. The default process to create translated content works this way: 1. Create an item and select its language, save it. Its the so called canonical item. 2. Select the language for translation in the content menu. A copy is created and a side-by-side view shows the new items form on the left and the canonical items content on the right. This need to be repeated for every language needed. I don't quite understand this. Does that mean that there will be some sort of a webinterface for doing translations of the content as well. If so that opens a whole new can of worms, but I'll let you answer the original questions first, the we can deal with the worms if it is relevant. However, we're unsure how graphics/pictures are translated. One possibility for handling localised graphics/pictures is the one currently used for the software documentation. It has the obvious advantage that we (translators) know it. So what happens is that in a po folder there is a subfolder C that contains the orginals, the english files, within that is another subfolder figures that contain the figures used in the documentation. So what we do to localise them is that under the po folder we create a subfolder for our language da and under that we create a similar subfolder called figure and then we simply place localised graphics/pictures in that folder with names identical to the originals, and then they will automaticalle get used. Since this structure is already used with xml2po I guess it would be easy to extend. The untranslated marker is removed as soon as one translation is pushed. If someone changes the English item the translated item isn't overwritten anymore. They may get out of sync until translation team uploads the updated translation again. Is that an established policy for the GNOME website? I'm only asking because I am coruous, not necessarily because I disagree. You should just know that for software and help pages they both revert to the english string if the english string is updated and the translation not yet updated, so the policy is that accuracy in the strings take priority over having the localised. Now I know it makes sense for software and documentation, but I'm not so sure for a website, someone needs to think about this, if they haven't already. My guess would actually be that it would be better to adopt this policy for the website as well. I can see that if translators are only a small commit, or a few months late in commiting an updated translation, then it makes sense to keep the translated string even if it is slightly outdated. But the reality of the translation world is the often enough it will take more time. Translating the GNOME website, even though I think it is important, will not be first (or even second) on our/my prioritised list as compared to software and documentation, and that means that as soon as we run low on resouces it will be one of the first ting to suffer. Also there is the possibility that some newly started laguages simply give up. In between these two options we may be looking at seriously outdated massages. I don't think it is fair to ask the users to figure that out on their own, and go to the english site for a newer version. Therfore, bottom line, I think that updated english messages should overwrite outdated translated ones. Regards Kenneth Nielsen ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
První překlad
Ahoj, začal jsem překládat nápovědy k programům, protože v těch to, co se týká češtiny, zatím moc slavné není. Pro začátek jsem přeložil nápovědu od kalkulačky (gcalctool). Je to můj první překlad přímo pro Gnome a nějak jsem úplně nepochopil co s ním. Z informací na webu jsem vytušil, že člověk musí mít git účet, ale ten dostane, až po schválení na základě nějakého ukázkového překladu. Komu ale ten překlad zaslat? Sem do konference? Marv ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: První překlad
2009/6/15 Marek Černocký ma...@manet.cz: Ahoj, začal jsem překládat nápovědy k programům, protože v těch to, co se týká češtiny, zatím moc slavné není. Pro začátek jsem přeložil nápovědu od kalkulačky (gcalctool). Je to můj první překlad přímo pro Gnome a nějak jsem úplně nepochopil co s ním. Z informací na webu jsem vytušil, že člověk musí mít git účet, ale ten dostane, až po schválení na základě nějakého ukázkového překladu. Komu ale ten překlad zaslat? Sem do konference? 1) please write your lists to this mailing list in English - there are people from all over the world. 2) git access is generally needed only for language coordinator. 3) generally you should send your translations to your coordinator; you can find his contacts on the appropriate language web page. Marv ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: krb5-auth-dialog proposal
(CC'ing gnome-i18n as this is mostly about translations.) Also see http://l10n.gnome.org/module/krb5-auth-dialog/ . Hi, Am Montag, den 15.06.2009, 10:38 +0200 schrieb Guido Günther: On Wed, May 13, 2009 at 09:13:31PM +0200, Guido Günther wrote: Restricting the extraction to src/lib/krb5/error_tables instead of the whole Kerberos source tree reduces the numboer of strings by a factor of two. Limiting the list to the most common errors returned by the Kerberos libs would make sense. I've implemented this and also added a note to translators where the strings in dummy-strings.c come from so they can skipped easily. 346 translatable strings now, compared to 637. Way better. Thanks! But having no experience with KRB5/such auth stuff at all, I still wonder how strings like Policy rejects transited path or Inappropriate type of checksum in message are helpful to an average user. What exactly am I (probably a user whose computer has been set up to use krb5) expected to do here when getting such an error message? I still see big issues in translating stuff like Ticket is ineligible for postdating if you're a translator who is not technically into KRB5. Also, can you please add a comment to msgid translator-credits? Also, is there any documentation available? Except for the above URL and the README not yet. It ships a manual now. Great. Thanks for your work! andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New GNOME Website - Translation
Hi Kenneth, I have had a look at the proposal. From what I can see it looks fine. What matters to us is that we can maintain the same workflows (fetch, translate, proofread, corrections, upload) that we usually use. From how I understand the proposal it will ultimately become possible to use po-files for everything, so in that case it's all flowers and sunshine. Yup (except we still need someone to write the glue code between Plone and the translation repositories (fetch, store, collect translations, push back to plone) and work out the details of the external api.) I do however have a couple of questions. The default process to create translated content works this way: 1. Create an item and select its language, save it. Its the so called canonical item. 2. Select the language for translation in the content menu. A copy is created and a side-by-side view shows the new items form on the left and the canonical items content on the right. This need to be repeated for every language needed. I don't quite understand this. Does that mean that there will be some sort of a webinterface for doing translations of the content as well. If so that opens a whole new can of worms, but I'll let you answer the original questions first, the we can deal with the worms if it is relevant. It's the interface that the default i18n implementation for Plone (LinguaPlone) offers. We will add an interface that can be used to fetch the orignal and upload translations (as xml). The web interface should not be used by translators. We can decide later what to do with the web interface, e.g. block it or keep it for special tasks However, we're unsure how graphics/pictures are translated. One possibility for handling localised graphics/pictures is the one currently used for the software documentation. It has the obvious advantage that we (translators) know it. So what happens is that in a po folder there is a subfolder C that contains the orginals, the english files, within that is another subfolder figures that contain the figures used in the documentation. So what we do to localise them is that under the po folder we create a subfolder for our language da and under that we create a similar subfolder called figure and then we simply place localised graphics/pictures in that folder with names identical to the originals, and then they will automaticalle get used. Since this structure is already used with xml2po I guess it would be easy to extend. The speciality with Plone is that a file is not only a file. It's a file with additionally (Meta)data used in the webpage (Title, Description, Tags, ...) The glue code between plone and the translation repositories has to deal with the storage part. The untranslated marker is removed as soon as one translation is pushed. If someone changes the English item the translated item isn't overwritten anymore. They may get out of sync until translation team uploads the updated translation again. Is that an established policy for the GNOME website? I'm only asking because I am coruous, not necessarily because I disagree. You should just know that for software and help pages they both revert to the english string if the english string is updated and the translation not yet updated, so the policy is that accuracy in the strings take priority over having the localised. Now I know it makes sense for software and documentation, but I'm not so sure for a website, someone needs to think about this, if they haven't already. The marker is a technical detail inside plone and will asure that the non englisch content (say french) is synced completely with the original englisch automatically if someone edits the original. From the moment that content receives a translation from the translation team, plone will not automatically sync the french content anymore if the original is changed. That will be the responsibility of the script that pull the original out of Plone and pushes it into the git repository (vice versa). My guess would actually be that it would be better to adopt this policy for the website as well. I can see that if translators are only a small commit, or a few months late in commiting an updated translation, then it makes sense to keep the translated string even if it is slightly outdated. But the reality of the translation world is the often enough it will take more time. Translating the GNOME website, even though I think it is important, will not be first (or even second) on our/my prioritised list as compared to software and documentation, and that means that as soon as we run low on resouces it will be one of the first ting to suffer. Also there is the possibility that some newly started laguages simply give up. In between these two options we may be looking at seriously outdated massages. I don't think it is fair to ask the users to figure that out on their own, and go to the english site for a newer version. Therfore, bottom line, I think that updated
Re: První překlad
Ahoj Marek, Am Montag, den 15.06.2009, 11:40 +0200 schrieb Marek Černocký: začal jsem překládat nápovědy k programům, protože v těch to, co se týká češtiny, zatím moc slavné není. Pro začátek jsem přeložil nápovědu od kalkulačky (gcalctool). Je to můj první překlad přímo pro Gnome a nějak jsem úplně nepochopil co s ním. For discussing language specific translation issues please subscribe and send an email to the Czech translation list. For more information see http://mail.gnome.org/mailman/listinfo/gnome-cs-list . Also see http://live.gnome.org/Czech/ . Z informací na webu jsem vytušil, že člověk musí mít git účet, ale ten dostane, až po schválení na základě nějakého ukázkového překladu. Komu ale ten překlad zaslat? Sem do konference? Please create an account at http://l10n.gnome.org/register/ , join the Czech team at http://l10n.gnome.org/languages/cs/ , and upload your translation to the corresponding module in http://l10n.gnome.org . Diký moc, andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New GNOME Website - Translation
Hi Kenneth, Hallo Carsten Before we go any further I should say that I am ONLY a translator, so all my previous comments was only from the perspective of a translator. I know very little about programming and all the other stuff that is used for this. I have had a look at the proposal. From what I can see it looks fine. What matters to us is that we can maintain the same workflows (fetch, translate, proofread, corrections, upload) that we usually use. From how I understand the proposal it will ultimately become possible to use po-files for everything, so in that case it's all flowers and sunshine. Yup (except we still need someone to write the glue code between Plone and the translation repositories (fetch, store, collect translations, push back to plone) and work out the details of the external api.) Oh yeah of course. But it is the plan as I read it, that's all I care about. I do however have a couple of questions. The default process to create translated content works this way: 1. Create an item and select its language, save it. Its the so called canonical item. 2. Select the language for translation in the content menu. A copy is created and a side-by-side view shows the new items form on the left and the canonical items content on the right. This need to be repeated for every language needed. I don't quite understand this. Does that mean that there will be some sort of a webinterface for doing translations of the content as well. If so that opens a whole new can of worms, but I'll let you answer the original questions first, the we can deal with the worms if it is relevant. It's the interface that the default i18n implementation for Plone (LinguaPlone) offers. We will add an interface that can be used to fetch the orignal and upload translations (as xml). The web interface should not be used by translators. Phew *Whipes cold sweat of his forehead* We can decide later what to do with the web interface, e.g. block it or keep it for special tasks However, we're unsure how graphics/pictures are translated. One possibility for handling localised graphics/pictures is the one currently used for the software documentation. It has the obvious advantage that we (translators) know it. So what happens is that in a po folder there is a subfolder C that contains the orginals, the english files, within that is another subfolder figures that contain the figures used in the documentation. So what we do to localise them is that under the po folder we create a subfolder for our language da and under that we create a similar subfolder called figure and then we simply place localised graphics/pictures in that folder with names identical to the originals, and then they will automaticalle get used. Since this structure is already used with xml2po I guess it would be easy to extend. The speciality with Plone is that a file is not only a file. It's a file with additionally (Meta)data used in the webpage (Title, Description, Tags, ...) The glue code between plone and the translation repositories has to deal with the storage part. Yes. But I don't see how that makes it more difficult. Put metadata in the po-file along with the rest of the document and the figure file in a folder with a unique (and non-localised) name. Then when fetching translations, get the translations from the po-file, check if the localised figure exist in a certain folder, if it does, use it, and if it does not, use the english one. Anyhow, as I said earlier, I don't know enough enough about the specifics of how this would be implemented to say whether it can be done or not. Let my simply say, from my pow it would be preferable to use the same structure as for the documentations figures. My guess would actually be that it would be better to adopt this policy for the website as well. I can see that if translators are only a small commit, or a few months late in commiting an updated translation, then it makes sense to keep the translated string even if it is slightly outdated. But the reality of the translation world is the often enough it will take more time. Translating the GNOME website, even though I think it is important, will not be first (or even second) on our/my prioritised list as compared to software and documentation, and that means that as soon as we run low on resouces it will be one of the first ting to suffer. Also there is the possibility that some newly started laguages simply give up. In between these two options we may be looking at seriously outdated massages. I don't think it is fair to ask the users to figure that out on their own, and go to the english site for a newer version. Therfore, bottom line, I think that updated english messages should overwrite outdated translated ones. I guess it's not even possible to use outdated translations if the original changed cause the msgid changed (to the updated englisch text) and this
Re: Aptitude Compile PO Help
Am Montag, den 15.06.2009, 13:18 +0200 schrieb Omar Campagne: I'm translating the aptitude user guide to spanish You probably want to contact the Spanish translation list instead at http://mail.gnome.org/mailman/listinfo/gnome-es-list though Aptitude has nothing to do with GNOME as far as I know. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New GNOME Website - Translation
Hi Kenneth, --On Montag, Juni 15, 2009 13:42:29 +0200 Kenneth Nielsen k.nielse...@gmail.com wrote: [...] However, we're unsure how graphics/pictures are translated. One possibility for handling localised graphics/pictures is the one currently used for the software documentation. It has the obvious advantage that we (translators) know it. So what happens is that in a po folder there is a subfolder C that contains the orginals, the english files, within that is another subfolder figures that contain the figures used in the documentation. So what we do to localise them is that under the po folder we create a subfolder for our language da and under that we create a similar subfolder called figure and then we simply place localised graphics/pictures in that folder with names identical to the originals, and then they will automaticalle get used. Since this structure is already used with xml2po I guess it would be easy to extend. The speciality with Plone is that a file is not only a file. It's a file with additionally (Meta)data used in the webpage (Title, Description, Tags, ...) The glue code between plone and the translation repositories has to deal with the storage part. Yes. But I don't see how that makes it more difficult. Put metadata in the po-file along with the rest of the document and the figure file in a folder with a unique (and non-localised) name. Then when fetching translations, get the translations from the po-file, check if the localised figure exist in a certain folder, if it does, use it, and if it does not, use the english one. Yes, that's a plan. As Jens and I are Plone guyes, the question was an attemp to get thoughts or an recommendation from someone who knows gnomes translation workflow :-) and an easy way to connect the two. [...] Anyway. I hope this was the kind of feedback you guys were looking for. Yes, thanks for the feedback. I appreciate it very much. ..Carsten ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: esperanta tradukado
Em Dom, 2009-06-14 às 14:05 +0100, Bruce Cowan escreveu: I implore you to just ignore Launchpad's Ubuntu translations. None of the work done there will ever find its way upstream. I used to be a en_GB translator there, but left after they made some bad decisions, and still didn't upstream anything (I was promised on joining that they would). Ubuntu makes it very easy for any one to translate, and the result is more volume and less quality. But it would make sense to take a look at the translations before discarding them. -- Leonardo Ferreira Fontenelle leonar...@gnome.org ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
ooo-build l10n
Hi all! It seems to me that ooo-build (http://git.gnome.org/cgit/ooo-build/) has migrated to use the git infrastructure at freedesktop.org (http://cgit.freedesktop.org/ooo-build/ooo-build), but the ooo-build guys somehow forgot to ping the GNOME Translation Project about it. Also see the following commit by Michael Meeks: http://git.gnome.org/cgit/ooo-build/commit/?id=37cfad29874e9a7fa0865220feaaf03dd9811516 Michael, I hope I'm sending the message to the right person, could you please tell GNOME translators (or point us to the appropriate person), which way should we submit our translations for ooo-build from now on? I guess we should use the freedesktop.org Bugzilla, right? Or do the ooo-build guys plan to make use of some existing l10n infrastructure, e.g. the Translation Project (http://translationproject.org)? Or perhaps you're going to periodically merge newly committed translations from the existing GNOME git repository? Because the situation seems to be that GNOME translators continue to submit their translation updates to git.gnome.org... TIA. Best regards, Petr Kovar ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
