On 06.09.2013 14:30, janI wrote:
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.
Keeping the admin out of the loop would be good. But having SVN
operations during every build would be bad.
If the commits and updates are done only on request by translators then
that would be fine. But if the build system does that on every build
automatically , the overhead might be too large.
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 think we should be a bit more specific here. I agree that the work of
translators and of developers is equally important. But there are
differences in their work flows that should not be neglected. I am not
a translator but I would expect that the majority of the work of
translators is done in Pootle (online or offline). Building OpenOffice
seems more like a last step to verify the translation results. In
contrast developers build OpenOffice, or at least parts of it, on a
regular basis. Sometimes several times an hour. That means that any
slowdowns of the build process affect translators and developers quite
differently.
I also think that each group does not need to integrate changes of the
other too frequently. When I fix a bug that does not affect any strings
then translators are probably not very interested in it. That works the
other way around as well. I do most of my development work with en_US.
I don't need frequent language updates to debug, fix, and verify bug
fixes that are not language dependent.
So, keeping the things somewhat separated make sense. But we should
find names that do not imply that one part is more important than the other.
Best regards,
Andre
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: [email protected]
For additional commands, e-mail: [email protected]
