Hi Jan,
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.
Yes, fine thing. Looking forward to it!
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.
+1, not really avoidable. Producing BuldBreakes is a fast teacher to get
better/more careful. The alternative is too complicated.
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).
Well, the goal is to keep stuff as simple as possible when we want to
attract new developers. Size of the checkout is one criteria of
'simple'. The build and stuff to checkout is already too big, reducing
it would be better than making it bigger.
Plese do not take the name 'extra' wordly, there are many necessary and
valuable things; take it the other way around: The non-extra should be
the minimal set to be able to work on the office as a developer.
Thus, I would prefer to keep main small. Maybe a new dir tree besides
main and extra ('translation', 'languages', ...) would be good and
self-explanatory.
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.
It is not ;-) My wife is a translator, I can tell you...
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@).
If it would not cause too much work to put that 600mb besides main I
would appreciate it. If it's much extra work, keep it as it is.
rgds
jan I.
Sincerely,
Armin
--
ALG
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
