But this probably adds nothing to what you already know: in other
words, the code<->Pootle conversions have always been "black boxes"
for translation teams.
Regards, Andrea.
Yes, that's (fortunately) been the case and should continue to be the case.
And I am a developer with limited knowledge about the localization
process. Maybe we can help each other.
It would help me, for example, if you could describe the localization
from you POV, like how you down- and later upload data from/to the
pootle server. When do you start translation, how do you signal that
you have finished translating and the uploaded data is ready for
integration?
-Andre
Sure. There's little in a way that I need to add to what Andrea said.
The black magic between the po files on Pootle and the rc / releases
must remain separate from the task of translation. Pootle server is
good, it allows on and offline collaboration, offline for example by
downloading the po files and then editing them in a translation memory
such as Virtaal which reduces the amount of re-translation.
There were and are (over on LO) no "signoffs" the way Mozilla has them.
There are translation deadlines and if a locale has completed a
sufficient amount of the UI by that date, then there will be a release
in that language. I know we had this debate about release vs language
pack; that should remain in the background, all the end user wants to
know is that they can get OO with the UI in their language.
I'm not sure if the upload options come with Pootle or if they must be
coded, i.e. you get the choice of Uploading and overwriting, Uploading
and turning conflicts into suggestions etc. If they need to be coded
manually, we can talk about that.
If you want to, you could sign up with the LO pootle server and I can
give you rights in Scots Gaelic so you can see how it works? I'm just
not sure what "comes with Pootle" and what doesn't, so perhaps the first
thing to do would be to get it up and running and see what that gives
you, perhaps with a small number of locales that we can test stuff with?
Since this is still fluid, I'd like to make an impassioned plea. We
should set intelligent cutoffs (note the plural). For most localizers,
the key part of OO/LO is Writer. But the localization process so far has
required teams to complete x% of the total UI. This is very unhelpful
and an obstacle to new locales, especially small ones. There's a
possibility here of making AOO very attractive to new, small locales by
introducing stepped localization i.e. we identify the strings which are
in Writer and allow releases for locales which have completed just
Writer, OpenOffice "light" in a sense. I know there's grey areas in
between (i.e. which strings show up where) but even just excluding those
which are clearly Draw/Calc/Database/Formula/Present makes localization
more manageable. OO has gotten fairly big.
Beyond that, ideall you simply add and additional translations to a
release but if someone argues heavily for doing it package by package
i.e. once you finish Draw, you also get Draw localized UI, then I won't
argue.
Michael
