openoffice-l10n mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Question to all developers and translators: How integrated should translation be ?
Date Fri, 06 Sep 2013 12:30:17 GMT
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.

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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message