What about let the customer choose it from the installation or after the the installation and integrate a menu command such as "Apply Vietnamese". Both of those will need online. By far, the world is online. So, keeping this idea will avoid the problem, along with the function such as "clip art".
On Fri, Sep 6, 2013 at 7:53 PM, Rob Weir <robw...@apache.org> wrote: > On Fri, Sep 6, 2013 at 8:30 AM, janI <j...@apache.org> 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. >> >> 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). >> > > I'd plan for growth here. I see no reason why we will not end up with > 100+ languages in the future. Certainly there were that many with > OpenOffice.org. So if we have 600Mb for 25 or so languages, will it > still be a reasonable layout when the languages take up 2.4 GB? > > -Rob > > > >> 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. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
