[opensuse-translation] Refresh pot files?
Hi all, according to the oS 12.1 roadmap[1], the last round of translations will start Sept. the 1st. As pointed out in previous messages, there are some translations that are not used by corresponding applications. This seems to be due to outdated pot files or to different msgids in po files and applications. Moreover, there are po files without corresponding pot files, such as html-help-boot.it.po, html-help-install.it.po, kfiledialog.it.po, kinternet.it.po and libgnomesu-1.0.it.po in lnc. Is it possible to refresh all pot files (and then all po files) in order to be sure to translate the right messages? Regards, Andrea [1] http://www.suse.de/~coolo/opensuse_12.1/ -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-05-16 10:36, Andrea Turrini wrote:
Hi all, according to the oS 12.1 roadmap[1], the last round of translations will start Sept. the 1st.
As pointed out in previous messages, there are some translations that are not used by corresponding applications. This seems to be due to outdated pot files or to different msgids in po files and applications.
Developers must take responsibility and generate the pot files everytime they change something, and upload that pot file to our server if it has changed. Being devs, they could automate this. Once that is done, we have tools to sync pots and pos.
Moreover, there are po files without corresponding pot files, such as html-help-boot.it.po, html-help-install.it.po, kfiledialog.it.po, kinternet.it.po and libgnomesu-1.0.it.po in lnc.
Orphans. Each team should delete them. Or move to an obsolete directory, because some times the translated strings can be reused.
Is it possible to refresh all pot files (and then all po files) in order to be sure to translate the right messages?
Unfortunately, there is no script we can run to make that happen. Not possible. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3RGtUACgkQtTMYHG2NR9UevwCePItPTh0jbzXoLHxT2Wc+G2qR g/oAn1QBxGuzM7aDltNOWt2owK4Zvryu =isFm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
2011/5/16 Carlos E. R. <carlos.e.r@opensuse.org>:
Developers must take responsibility and generate the pot files everytime they change something, and upload that pot file to our server if it has changed. Being devs, they could automate this.
And is it possible to convince them to do this? For example, adding a new event in the roadmap (say, one week before MS5) where devs should update pot files.
Moreover, there are po files without corresponding pot files, such as html-help-boot.it.po, html-help-install.it.po, kfiledialog.it.po, kinternet.it.po and libgnomesu-1.0.it.po in lnc.
Orphans. Each team should delete them. Or move to an obsolete directory, because some times the translated strings can be reused.
In my opinion, it should be managed in a centralized way: there should be a common folder (say "discontinued" or "removed") at the same level of lcn and yast, containing the trees with root lcn, yast, and webyast; once a pot file is removed from svn, then all corresponding po files should be moved in the corresponding place inside "discontinued". I do not know how easy it is to write a similar script, but it can be useful: translators should not care whether a po file is orphan and they know where to find orphan files if they need of an already translated string. Regards, Andrea -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-05-17 13:21, Andrea Turrini wrote:
2011/5/16 Carlos E. R. <carlos.e.r@opensuse.org>:
Developers must take responsibility and generate the pot files everytime they change something, and upload that pot file to our server if it has changed. Being devs, they could automate this.
And is it possible to convince them to do this? For example, adding a new event in the roadmap (say, one week before MS5) where devs should update pot files.
It should be part of the routine. Every time there is a release, it should be done.
Orphans. Each team should delete them. Or move to an obsolete directory, because some times the translated strings can be reused.
In my opinion, it should be managed in a centralized way: there should be a common folder (say "discontinued" or "removed") at the same level of lcn and yast, containing the trees with root lcn, yast, and webyast; once a pot file is removed from svn, then all corresponding po files should be moved in the corresponding place inside "discontinued".
That's a good idea.
I do not know how easy it is to write a similar script, but it can be useful: translators should not care whether a po file is orphan and they know where to find orphan files if they need of an already translated string.
If I recall correctly, the vertaal tool from Gabriel some teams use, watches for this situation. [...] Mmm, no, it is not doing that. The "html-help-install" file doesn't show a problem. :-? - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ShicACgkQtTMYHG2NR9XSSgCeIYt9l+mycZ0exjPX20WoHxAW rScAoIK1B9Vuttchzz61CHUWxQfRdoae =9Siq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Andrea Turrini <andrea.turrini@gmail.com> writes:
2011/5/16 Carlos E. R. <carlos.e.r@opensuse.org>:
Developers must take responsibility and generate the pot files everytime they change something, and upload that pot file to our server if it has changed. Being devs, they could automate this.
And is it possible to convince them to do this? For example, adding a new event in the roadmap (say, one week before MS5) where devs should update pot files.
I guess, we just must tell coolo about it when we agree. In the past, I sent notification mails to the developers either to update the pot files, or adding done translations to their packages. There is a simple script that can help with these reminders: 50-tools/maintainer-reminder.sh
In my opinion, it should be managed in a centralized way: there should be a common folder (say "discontinued" or "removed") at the same level of lcn and yast, containing the trees with root lcn, yast, and webyast; once a pot file is removed from svn, then all corresponding po files should be moved in the corresponding place inside "discontinued".
Personally, I do not like these "discontinued" directories. I'd rather vote to add all good translations to the memory or compendium files, and then simple remove the outdated translation files. There also exists a script: 50-tools/lcn-remove-textdomain.sh
I do not know how easy it is to write a similar script, but it can be useful: translators should not care whether a po file is orphan and they know where to find orphan files if they need of an already translated string.
The "problem" is that nobody will tell you in advance, which files are obsolete. YOu usually must ask the old maintainer or project guru.
From time to time I try to do a little bit cleanup in this area. Thanks for your input, which is very useful!
-- Karl Eichwalder - R&D / Documentation SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg), Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-05-17 16:35, Karl Eichwalder wrote:
Andrea Turrini <andrea.turrini> writes:
Personally, I do not like these "discontinued" directories. I'd rather vote to add all good translations to the memory or compendium files, and then simple remove the outdated translation files.
But in the compendium it is not possible to evaluate when strings are too old and should also be removed from memory. Also, the strings are out of context. Both things can be done, have the compendium and the discontinued archive.
There also exists a script:
50-tools/lcn-remove-textdomain.sh
I do not know how easy it is to write a similar script, but it can be useful: translators should not care whether a po file is orphan and they know where to find orphan files if they need of an already translated string.
The "problem" is that nobody will tell you in advance, which files are obsolete. YOu usually must ask the old maintainer or project guru. From time to time I try to do a little bit cleanup in this area. Thanks for your input, which is very useful!
Well, if the .pot disappears, the .po has to be removed as well, no? - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3Ssw0ACgkQtTMYHG2NR9U2CQCeKkOJslhAJ74eeXivDmAhExFu fg0AmQG0kKye2uuyhPbBF+BtKKWuKVkk =YyMU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
"Carlos E. R." <carlos.e.r@opensuse.org> writes:
On 2011-05-17 16:35, Karl Eichwalder wrote:
But in the compendium it is not possible to evaluate when strings are too old and should also be removed from memory. Also, the strings are out of context.
Both things can be done, have the compendium and the discontinued archive.
Yeah. And yes, the "normal" gettext compendium approach is rather limited. Maybe, it is worth trying to preserve the translations in the xliff format and deriving .po compendia as needed. I think I'll give this a whirl. Wondering what's the state of the art with xliff and free CAT systems? (CAT == computer aided translation)
Well, if the .pot disappears, the .po has to be removed as well, no?
Yes, agreed ;) To be sure, you can check the MAINTAINERS file first using 50-tools/lcn-check-maintainers.sh . -- Karl Eichwalder - R&D / Documentation SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg), Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Onsdag den 18. maj 2011 09:48:20 skrev Karl Eichwalder:
"Carlos E. R." <carlos.e.r@opensuse.org> writes:
On 2011-05-17 16:35, Karl Eichwalder wrote:
But in the compendium it is not possible to evaluate when strings are too old and should also be removed from memory. Also, the strings are out of context.
Both things can be done, have the compendium and the discontinued archive.
Yeah. And yes, the "normal" gettext compendium approach is rather limited. Maybe, it is worth trying to preserve the translations in the xliff format and deriving .po compendia as needed. I think I'll give this a whirl.
Wondering what's the state of the art with xliff and free CAT systems? (CAT == computer aided translation)
Wonder if this TMX format which Lokalize can import/export could be usable. Don't know anything about it, but I assume it's some XML based format. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Hi, On 2011-05-18 09:48, Karl Eichwalder wrote:
"Carlos E. R."<carlos.e.r@opensuse.org> writes:
On 2011-05-17 16:35, Karl Eichwalder wrote:
But in the compendium it is not possible to evaluate when strings are too old and should also be removed from memory. Also, the strings are out of context.
Both things can be done, have the compendium and the discontinued archive.
Yeah. And yes, the "normal" gettext compendium approach is rather limited. Maybe, it is worth trying to preserve the translations in the xliff format and deriving .po compendia as needed. I think I'll give this a whirl.
just happened to notic this thread, got to be off so I'll pop back in when I'm back, but XLIFF is intended for translation exchange. That's not to say it can't be used for translation memory, but TMX is the translation memory exchange format.
Wondering what's the state of the art with xliff and free CAT systems? (CAT == computer aided translation)
As I said, will pop back in later, but here's one tool: <http://www.omegat.org/en/howtos/compatibility.html> Apropos Lokalize, Nick Shaforostoff seems to be keen on catching and implementing improvements. Perhaps he could add a context parsing bit. Dunno if anyone remembers my input a few years ago about hierarchical subject tagging and making subject trees for a wide range of open source software, allowing among other things some control over keyboard shortcut clashes. BR, Gudmund -- This message and any replies to it is scanned by http://www.fra.se. Please direct any complaints about this to them. -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-05-18 09:48, Karl Eichwalder wrote:
Wondering what's the state of the art with xliff and free CAT systems? (CAT == computer aided translation)
No idea about that. - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3T0e4ACgkQtTMYHG2NR9VjeACfcUUlM5myfIV9SPpLVmNtIO1A R7cAn36xRoPtL1KvGfJyJstbQNZImUXK =LhaA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
Tysdag 17. mai 2011 skreiv Carlos E. R.:
Personally, I do not like these "discontinued" directories. I'd rather vote to add all good translations to the memory or compendium files, and then simple remove the outdated translation files.
But in the compendium it is not possible to evaluate when strings are too old and should also be removed from memory. Also, the strings are out of context.
The ‘best’, heavy-duty, solution is probably to use the Pology Ascription framework: http://techbase.kde.org/Localization/Workflows/PO_Ascription and http://article.gmane.org/gmane.comp.kde.devel.internationalization-and-docum... However, for most teams this will be overkill, and just keeping the outdated translation file stored in a local directory would be OK. Personally, I would just delete the file. There are plenty of *current* translation sources for creating compendia; you don’t have to keep old ones around. -- Karl Ove Hufthammer http://huftis.org/ Jabber: karl@huftis.org -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org
participants (6)
-
Andrea Turrini
-
Carlos E. R.
-
Gudmund Areskoug
-
Karl Eichwalder
-
Karl Ove Hufthammer
-
Martin Schlander