Re: Repetitive strings in many modules
On Sat, Sep 15, 2012 at 9:04 PM, Ask Hjorth Larsen asklar...@gmail.com wrote: Hi translators and i18n people I notice that the string Quit seems to have appeared in quite a few modules. In total, the msgids Quit or _Quit (i.e. matching ^(_?)Quit$) are found 31 times, in these modules: Why not use a stock label for this kind of stuff? There are also many instances of About and _About which I don't recall from previous releases. Regards Ask Yes, Strings like this are a good reason to use an off-line PO editor with a good translation memory feature or an on-line tool like Pootle that has a glosssary/terminology project. It would be a thought to crunch a glossary.po terminology project for GNOME using poternimology from theTranslate Toolkit. At the very least, people could download it to their local TM to help maintain consistency in translations of certain common terms. The main problem (as I see it) is that GNOME is not a monolithic project. It is a very large collection of independent projects that strive to be interoperable. I don't know that carving strings like this out into a separate software package called when needed would ever really work for the developers. They would simply introduce the strings they feel they need for their UI and not reference an external source for them. It is far too great a social engineering problem. As a simply technical matter it is much easier to address this issue by working with a local TM. I am entirely in favor of filing i18n bugs to promote common-sense string conventions when possible (Why have Zoom in and Zoom In and 'ZOOM IN if you can possibly agree on one string), but even then it is a matter of getting devs to agree on one convention. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[gtkhtml] Created branch gnome-3-6
The branch 'gnome-3-6' was created pointing to: d4244e8... Bump version to 4.6.0. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[evolution] Created branch gnome-3-6
The branch 'gnome-3-6' was created pointing to: 7dc4270... Post-release version bump. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[evolution-data-server] Created branch gnome-3-6
The branch 'gnome-3-6' was created pointing to: 46dad61... Post-release version bump. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
[evolution-ews] Created branch gnome-3-6
The branch 'gnome-3-6' was created pointing to: 1efcd41... Post-release version bump. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New team for Marathi (mr)
El dg 16 de 09 de 2012 a les 11:25 +0530, en/na Abhay Jayant Kadam va escriure: Hi All, I wish to revive the Marathi language translation team. My details are as follows: Name: Abhay Jayant Kadam Email: abhayka...@fedoraproject.org Bugzilla: abhaykada...@gmail.com Language details: English Name: Marathi Native Name: मराठी ISO 639 Code: mr The current coordinator is inactive for more than last two years. We can check that from the link: http://l10n.gnome.org/users/sandeeps/ His last activity is recorded on March 26, 2010. The team details on page http://l10n.gnome.org/teams/mr/ show that currently there are no committers, and no reviewers. Also, it list 11 inactive members. Furthermore, the Marathi translation team page http://www.indictrans.org/ is up for sale. I tried to contact with the coordinator, but to no avail. So, i guess, it's the time to revive the team. Thanks, Abhay Hi Abhay, great to hear a language coming back to action! Before we appoint you as the new coordinator, please, could you send this exact mail but CC'ing the current, supposedly inactive, coordinator? So that we let him a chance to actually say something? If in a week or so he hasn't replied, reply again to that message and we will change it. I know this could seem that can take a long time, but keep in mind that you can register and translate as much as you want and attach your translations on the modules. Later, when you get the coordinator status (or if the current coordinator replies) we will upload the translations right away. Happy translating! -- Gil Forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net planet: http://planet.guifi.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Repetitive strings in many modules
El dg 16 de 09 de 2012 a les 10:56 -0400, en/na Chris Leonard va escriure: On Sat, Sep 15, 2012 at 9:04 PM, Ask Hjorth Larsen asklar...@gmail.com wrote: Hi translators and i18n people I notice that the string Quit seems to have appeared in quite a few modules. In total, the msgids Quit or _Quit (i.e. matching ^(_?)Quit$) are found 31 times, in these modules: Why not use a stock label for this kind of stuff? There are also many instances of About and _About which I don't recall from previous releases. Regards Ask Yes, Strings like this are a good reason to use an off-line PO editor with a good translation memory feature or an on-line tool like Pootle that has a glosssary/terminology project. It would be a thought to crunch a glossary.po terminology project for GNOME using poternimology from theTranslate Toolkit. At the very least, people could download it to their local TM to help maintain consistency in translations of certain common terms. Fully agree, another reason to make damned-lies be able to generate one and use it while pre-translating the downloadable po files, so that you will already see them fuzzy. The main problem (as I see it) is that GNOME is not a monolithic project. It is a very large collection of independent projects that strive to be interoperable. I don't know that carving strings like this out into a separate software package called when needed would ever really work for the developers. They would simply introduce the strings they feel they need for their UI and not reference an external source for them. It is far too great a social engineering problem. Sure, social engineering, but if we can solve in our way, local TM, damned-lies pre-translating... we will not need to ask developers to update their code. As a simply technical matter it is much easier to address this issue by working with a local TM. I am entirely in favor of filing i18n bugs to promote common-sense string conventions when possible (Why have Zoom in and Zoom In and 'ZOOM IN if you can possibly agree on one string), but even then it is a matter of getting devs to agree on one convention. That's another issue that I would really like to see happening, someone stepping in and adding some cohesion/consistency to original strings. a GWOP/GHOPC would be really useful here. Anyone stepping in to do administrate it? :) Cheers, cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n -- Gil Forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net planet: http://planet.guifi.net ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: intltool-update does not display warnings if there is no error
Le samedi 15 septembre 2012 à 00:09 +0200, Gil Forcada a écrit : El dl 10 de 09 de 2012 a les 23:44 +0200, en/na Bruno Coudoin va escriure: Hi, I just found out that when intltool-update hits an error (like an xml file parsing) I get the error an saw a bunch of warnings. These warnings was about non named parameters. Once I fixed the error, these warnings are no more displayed (on the command line and on my http://l10n.gnome.org module page) This is unfortunate because there is no chance I will fix them if they are not reported. I tried the option -x (verbose) without success. Bruno. Hi Bruno, Sorry for this late response, but what's your request/wish here about? Do you want l10n.gnome.org to do/not to do something? Or is that on the intltool-update level? Sorry is not clear to me (and maybe it's too late for reading mails anyway :) Hi, Sorry for not being clear. I wanted to share my pain with you to see if this also impacts you. I just created a bug here (I hope it is the right place): https://bugs.launchpad.net/intltool/+bug/1051654 Bruno. ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Repetitive strings in many modules
On Sun, Sep 16, 2012 at 12:31 PM, Gil Forcada gforc...@gnome.org wrote: I am entirely in favor of filing i18n bugs to promote common-sense string conventions when possible (Why have Zoom in and Zoom In and 'ZOOM IN if you can possibly agree on one string), but even then it is a matter of getting devs to agree on one convention. That's another issue that I would really like to see happening, someone stepping in and adding some cohesion/consistency to original strings. a GWOP/GHOPC would be really useful here. Anyone stepping in to do administrate it? :) Can you define the acronyms GWOP/GHOPC? I am generally interested in cross-project consistency. First, there is the purpose of providing a user experience that enhances package-to-package transferable skills learning (as in Gee, I bet I know what 'Save' does, but I have no idea what this 'Preserve' / 'Retain' / 'Keep' item in the pull-down menu means). Consistency of original string (and its translation) in common pull-down menu items (in particular) is a desirable feature, not always attainable, but worth working towards. It is also a lot easier to look for consistency in translations if there is consistency in the original en_US strings. Subtle, but essentially meaningless, variations in the original (e.g. capitalization, punctuation on short strings, etc.) just makes those larger-scale translation consistency analyses more complex. Secondly, there are the hopefully obvious advantages to localizers in making on-line translation memory efforts more useful (e.g. Amagama, open-trans.eu, etc.), again it helps if the en_US strings have a sensible consistency. There will not always be a one-to-one match from an en_US string to a term in a given language, context is obviously critical, but that is why we have human translations, to include the critical element of judgment. The language universe of computer program UIs is somewhat more limited than the full complexity of human language. There are only so many ways to describe the functions performed by a word processor or a chess game. Voluntarily adopted consistency in terms may seem to be an overly ambitious goal, but I think even incremental progress is worth achieving. We should not even attempt to achieve the level of mandated consistency seen in fields like medical encoding (HL7, MEDRA, ICD-10, etc.), but as a professional user of those sorts of controlled vocabularies and ontologies, there are elements those approaches to knowledge representation that are worth emulating on a smaller scale. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: intltool-update does not display warnings if there is no error
On Sun, Sep 16, 2012 at 1:59 PM, Bruno Coudoin bruno.coud...@gcompris.net wrote: Sorry for not being clear. I wanted to share my pain with you to see if this also impacts you. I just created a bug here (I hope it is the right place): https://bugs.launchpad.net/intltool/+bug/1051654 Bruno, You have my sympathy on your intltool problem. intltool is apparently causing a number of issues for i18n of downstream projects WebKitGTK+ intltool problem https://bugs.launchpad.net/intltool/+bug/823217 GIMP intltool problem https://bugs.launchpad.net/intltool/+bug/986897 I was not entirely comforted nor satisfied by the intltool dev's reply on the WebKitGTK+ ticket, which was more or less, if it bothers you, then provide a patch. I hope you get a more satisfactory response. I wish I had something more encouraging to offer than that gloomy assessment. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Repetitive strings in many modules
Hi 2012/9/16 Chris Leonard cjlhomeaddr...@gmail.com: On Sat, Sep 15, 2012 at 9:04 PM, Ask Hjorth Larsen asklar...@gmail.com wrote: Hi translators and i18n people I notice that the string Quit seems to have appeared in quite a few modules. In total, the msgids Quit or _Quit (i.e. matching ^(_?)Quit$) are found 31 times, in these modules: Why not use a stock label for this kind of stuff? There are also many instances of About and _About which I don't recall from previous releases. Regards Ask Yes, Strings like this are a good reason to use an off-line PO editor with a good translation memory feature or an on-line tool like Pootle that has a glosssary/terminology project. It would be a thought to crunch a glossary.po terminology project for GNOME using poternimology from theTranslate Toolkit. At the very least, people could download it to their local TM to help maintain consistency in translations of certain common terms. I don't really mind *translating* them - they are very small strings in any case. But they have to be reviewed and go through the whole procedure, and it adds up a bit no matter whether you have a compendium or not (a compendium helps a lot with the license texts though). But it was my impression that one instead uses stock labels like the Save as... and About. Don't we have those? Also, not too many releases ago something similar happened where several messages appeared in many modules. Like Unrecognized desktop file version (I still remember that one). It's a bit strange, that's why I ask. Regards Ask ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Repetitive strings in many modules
On Sun, Sep 16, 2012 at 3:10 PM, Ask Hjorth Larsen asklar...@gmail.com wrote: Also, not too many releases ago something similar happened where several messages appeared in many modules. Like Unrecognized desktop file version (I still remember that one). It's a bit strange, that's why I ask. Regards Ask I can't say for sure, but it is always possible that such a flurry of common UI strings simultaneously appearing in different projects could perhaps come about because of coordinated efforts via the Gnome Goals https://live.gnome.org/GnomeGoals/ For example this one: https://live.gnome.org/GnomeGoals/RemoveMarkupInMessages will hopefully result in a large number of PO files being modified to remove the markup (xmltags) that often appear in strings. However, that is purely speculation on my part about the appearance of About strings in this case. cjl ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Repetitive strings in many modules
2012/9/16 Chris Leonard cjlhomeaddr...@gmail.com: However, that is purely speculation on my part about the appearance of About strings in this case. This is actually an effect of https://live.gnome.org/GnomeGoals/PortToGMenu goal. The new menus don't use stock GTK+ entries for some reason. -- Piotr Drąg http://raven.fedorapeople.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Errors in documentation tags
2012/9/15 Alexandre Franke alexandre.fra...@gmail.com: Can you try amp; as a replacement of the ampersand and see if it fixes the error? If it doesn't work, try with %26. Please note that a file has been uploaded to Vertimus for this translation (so fixing it in master may not be the right choice as the fix may be lost when commiting the new file). I don't have access to the script, so I can't check if it would help. -- Piotr Drąg http://raven.fedorapeople.org/ ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
String additions to 'gnome-control-center.master'
This is an automatic notification from status generation scripts on: http://l10n.gnome.org. There have been following string additions to module 'gnome-control-center.master': + In order to use enterprise logins, this computer needs to be\nenrolled in the domain. Please have your network administrator\ntype their domain password here. Note that this doesn't directly indicate a string freeze break, but it might be worth investigating. http://git.gnome.org/browse/gnome-control-center/log/?h=master ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Errors in documentation tags
Hi 2012/9/16 Piotr Drąg piotrd...@gmail.com: 2012/9/15 Alexandre Franke alexandre.fra...@gmail.com: Can you try amp; as a replacement of the ampersand and see if it fixes the error? If it doesn't work, try with %26. Please note that a file has been uploaded to Vertimus for this translation (so fixing it in master may not be the right choice as the fix may be lost when commiting the new file). I don't have access to the script, so I can't check if it would help. If you just need to run it on one file, use 'gtxml filename.po'. gtxml is part of pyg3t and can be found here: https://launchpad.net/pyg3t Note that gtxml only verifies that the xml isn't broken. (One can still write valid xml using tags which are not recognized in the GNOME docs, and thus wrong) Best regards Ask ___ gnome-i18n mailing list gnome-i18n@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-i18n
