openoffice-l10n mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aivaras Stepukonis <>
Subject Re: Question to all developers and translators: How integrated should translation be ?
Date Fri, 06 Sep 2013 12:57:21 GMT

2013.09.06 15:30, janI rašė:
> Hi
> I am copying this mail to the l10n list, in order to involve the
> translators that do not follow dev@. But lets please keep the discussion on
> dev@.
> As its hopefully known, I have been working on a new workflow for the whole
> translation process for quite a long time.
> Now I have released the first major part of the workflow, my ultimate
> commit has lead to some valid concerns from Jürgen and Herbert, this is the
> second time (during development) that I hear the essentially same concern.
> Therefore we a a community need to decide which road we want to follow.
> The workflow I am developing, would in the final phase look like (without
> technical details).
> 1) at regular intervals en-US text are extracted from our source tree,
> transferred to pootle as templates, and all languages are updates with
> new/changed/deleted keys. This part is partly manual (starting the build,
> updating the languages).
> 2) Translators work on pootle, Translator-comitters update languages in svn
> from pootle and start an offline language-pack build.
> 3) Translators test their translation using the binary from our buildbot  +
> language pack (translators debug tool). Turnaround time < 1 day.
> 4) Buildbot automatically include changed translations on regular builds
> (e.g. weekly).
> The 2 concerns that have been raised are:
> 1) Letting committers do "svn commit" and "svn up" directly in pootle,
> might produce a build breaker for our buildbots. Suggestion let an admin do
> it e.g. once a week.
> my opinion: We do not need an admin in the loop, we dont have a controlling
> for developers and they are even more likely to produce build breakers.
> Remember a .po file build breaker will only affect the language in question
> and can be repaired just as fast.
> 2) Containing the .po files (translations) inside main/ cost 600Mb extra
> for en-US developers to download. Suggestion keep the .po file away from
> main in extras.
> my opion: Translator work is NOT "extra", its an essential needed part for
> our builds. In contrast to e.g. cliparts, the .po are part of the setup
> package (of course transformed, similar to a C++ source).
> My workflow can work, not as efficient with 1), but 2) breaks the workflow
> for technical reasons (think of someone extracting en-US strings from an
> updated /main to an old /extra and the published it to pootle == LOT of
> extra translation in all languages.
> I see translators working at the same level as developers, not as something
> /extras, and therefore the work should be treated as such.
This premise cannot be stressed enough! I'd even go as far as to say, 
that they're as much developers as their programming colleagues, the 
differences being that they're developing the part of software that 
relies on natural language while the programmers are developing the part 
that relies on artificial language. The morale? The "translatability" of 
the software should be planned at the architectural stage of software 
development and translators should be part of that stage.

I'll file up a separate issue on this topic in a couple of weeks when I 
have more time.
> I have stopped work on further integration of genLang, until I either get
> lazy consensus on my workflow, or we decide to go for another workflow.
> thanks in advance for your comments (please all on dev@).
> rgds
> jan I.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message