2011/5/16 Carlos E. R. :

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

Andrea Turrini writes:

2011/5/16 Carlos E. R. :

...

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

"Carlos E. R." 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

Hi, On 2011-05-18 09:48, Karl Eichwalder wrote:

"Carlos E. R." 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

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