Re: What can Git do for translators?

[Goran Rakic <grakic devbase net>]

У чет, 08. 01 2009. у 18:19 -0600, Federico Mena Quintero пише: 
> 
> However, I'm not 100% sure about the workflows that translators tend to
> use.
>

Usually every team has a few people who are commiters (including team
coordinator).

People that just want to do translation, they tend to download updated
PO file from Damned Lies (http://l10n.gnome.org) and send it to project
mailing list, coordinator or one of "trusted commiters". Now it's
possible to send it to commiters via Damned Lies too.

There are also people that want to peek inside sources while translating
or they want to test translations by building and running applications
so they like to checkout complete module. No difference from any other
here.

Somebody said in this thread that there are people that want to fetch
just "po" subdir. The only scenario I can came up with is that there are
commiters with slow Internet access... In any case they must download PO
file from Damned Lies as source is needed to update file with new
messages. Translators who don't need complete source can download
tarball with all PO files from Damned Lies.

Review process is important inside workflow, and I think that every team
has its own best practice according to team size and resources, but I
don't believe it is different than translating from a perspective of
version control.

And everybody need revisions (even broken ones with non-aligned PO files
are better than none). Those without sources can use viewvc interface.
After getting two versions (by download or checkout), one must align two
PO files with msgcat tool before doing diff. (Get revision from last
review, align it with trunk and then compare in diff-tool like meld to
review changes and fix errors, for example)


Inside string freeze some modules branch early for release and commiters
need to commit translation both to string-frozen branch and later to
trunk (I like to do this immediately not to forget later). Once again,
there is noting translation-specific inside.


For large teams, it may prove (I'm just guessing, Serbian team is small)
useful to have one repository for all PO files, grouped by language so
translators, editors, commiters and coordinator can all work in a
distributed environment without cloning everything else.

This would in addition solve repository-size issue too, and those
wanting sources can get them too. KDE is using this approach.

It is important to note that not having this will NOT be a drawback from
current svn-based solution and we can always think about it in the
future.


--
Goran