translation management with transifex for epubcheck 4.0?

[Tobias]

Hey,

as it is possible to translate epubcheck messages with upcoming version 4.0 to other languages than english (thanks to the Barnes&Noble contribution) and there exist some translations yet (Japanese, French (parts), German (not merged yet), Spanish (parts)), I've been wondering whether we could improve the translation workflow somehow.
I'm fearing the situation when translations are drifting apart because their maintainers doesn't watch changes to the english master message files...

I remembered that I once signed up for Transifex (though never used it until now), which offers free translation management for Open-Source projects, and created an IDPF organization and an EpubCheck project: https://www.transifex.com/projects/p/epubcheck/

I added all current translations to the transifex project and set up the transifex commandline integration with PullRequest #479: https://github.com/IDPF/epubcheck/pull/479

There are still a few TODOs to manage and I'd like to hear your feedback on this topic.

Wanna give it a try and tell me what you think?

• Is it too much overhead?
• Shall we just don't care about outdated translations?
• Are there better tools for translation management?
• How to solve some of the open TODOs?

Take a look at PullRequest #479 (https://github.com/IDPF/epubcheck/pull/479) and leave a comment...

Thanks! Cheers,

Tobias

[Ori Idan]

Hi Tobias and all,

It seems like we have to build scripts that will work similar to GNU gettext that will generate the sources for the tests.

-- 

Ori Idan CEO Helicon Books

http://www.heliconbooks.com

--
You received this message because you are subscribed to the Google Groups "epubcheck" group.
To unsubscribe from this group and stop receiving emails from it, send an email to epubcheck+...@googlegroups.com.
To post to this group, send email to epub...@googlegroups.com.
Visit this group at http://groups.google.com/group/epubcheck.
For more options, visit https://groups.google.com/d/optout.

[Tobias]

Hi Ori,
I'm afraid, but I think I can't follow you a 100%...

Do you mean generating localized sources for the unit tests?
But this wouldn't test whether a message (or part of it) is translated or not, would it?

The point is, that we're able to translate messages with 4.0 and that some translations yet exist – and we somehow have to make sure that these translations will be maintained in the future.
Otherwise we should drop the localization feature (?)

So my thought was to introduce a tool for translators and maintainers to easily see which messages / text strings changed in development and need attention in translation...

But probably I'm just worrying too much about translations drifting apart...

/Tobias

[Ori Idan]

On Tue, Nov 4, 2014 at 12:46 AM, Tobias <tobias.ca...@gmail.com> wrote:

Hi Ori,
I'm afraid, but I think I can't follow you a 100%...

Do you mean generating localized sources for the unit tests?
But this wouldn't test whether a message (or part of it) is translated or not, would it?

The point is, that we're able to translate messages with 4.0 and that some translations yet exist – and we somehow have to make sure that these translations will be maintained in the future.
Otherwise we should drop the localization feature (?)

So my thought was to introduce a tool for translators and maintainers to easily see which messages / text strings changed in development and need attention in translation...

But probably I'm just worrying too much about translations drifting apart...

/Tobias

In order to introduce such a tool for translators, we need to mark in the test files which strings are to be translated thus we need a tool (script) that will take the translations from the translators and put them in the right places.

This is what I meant.