On 9/4/13 5:56 PM, janI wrote: > On 4 September 2013 17:10, Herbert Duerr <h...@apache.org> wrote: > >> On 04.09.2013 16:13, janI wrote: >> >>> On 4 September 2013 13:59, Herbert Duerr <h...@apache.org> wrote: >>> >>> On 04.09.2013 11:15, j...@apache.org wrote: >>>> >>>> Author: jani >>>>> Date: Wed Sep 4 09:13:51 2013 >>>>> New Revision: 1519953 >>>>> >>>>> URL: http://svn.apache.org/r1519953 >>>>> Log: >>>>> update to UTF-8 >>>>> >>>>> >>>> Great, thanks! And kudos to Tsutomu too! >>>> >>>> But I noticed that in the l10n40 branch the *.po files of all languages >>>> are checked in amidst the main source code in the main/languages >>>> directory. >>>> Wouldn't it be better to keep all these 600 megabytes of localization >>>> data >>>> separate, e.g. in extras/ where it used to be? >>>> >>>> >>> In my opinion po files are just as much source as any other part of main, >>> and not something extra. >>> >>> When using the argument "extra", we should move quit a lot of modules away >>> from main, since they are not compiled into our release (at least as far >>> as >>> what I can see). >>> >> >> Yes, I agree. A lot of modules belong into ext_libraries for example >> avmedia, beanshell, curl, epm, graphite, hyphen, jpeg, libpng, libxml2, >> libxmlsec, libxslt, lucene, moz, nss, openssl, python, redland, rhino, >> saxon, tomcat, vigra, zlib, ... >> >> >> main/languages and main/l10ntools forms together with a couple of other >>> modules (like i18n( our integrated international part, The intention of >>> the >>> new toolset is to make a deeper integration and not push it further away. >>> >> >> In the example above with all the external modules we already have such a >> tight integration that simply moving them into ext_libraries is a >> non-trivial task. Our goal should not be to tighter integrate them into our >> codebase but to work towards using the off-the-shelf releases of them. >> Using them better with their published interfaces is a worthwhile goal. >> >> The localizations have a clearly defined tasks and they are huge. When >> major UI changes are underway they create heavy commit traffic. When >> researching the code history or when bisecting for regressions these >> commits cost extra time. And since we are considering to commit directly >> into the l10n repository from pootle this commit rate could increase by >> orders of magnitude. > > > I just wonder what would happen if we had as many developers equally active > as our translators, then the problem would be very much the same. > > I have to ask very clearly; is the opinion of the community, that .po files > is not to be considered a vital/integrated part of our source tree and > should be moved away ? While at the same time accepting (at least for now), > that modules as mentioned above remain in our source tree and disturb > developers.
this question is obsolete and we all agree that the translations are essential as everything else in the code. We just gave you an example of a typical workflow and it becomes potentially better with smaller po files compared to 1 big sdf file per language. And the modules you have mentioned are completely different and we can of course discuss to remove them or store them in a different place. As always somebody has to do the work and it is often not only a simple remove. > > If the .po files are considered inferior, and disturbing, I will of course > not try to make an automated workflow that depend on integration. We just discuss what's better and we have at the moment different opinions. It's not an either or it's just seeking for the best approach to make all happy and to find the best solution. If we can define and ensure an automated workflow with continue integration of translation I am fine and happy with it. But if it breaks the build on a regular basis I am not. And by the way I believe an automated workflow can be achieved in different ways. And having the po files not in main but for example in extras don't change this. Or maybe you have something in mind that we don't see or understand at the moment. But we are interested to learn and hear more ... Juergen > > rgds > jan I. > >> >> >> Herbert >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@openoffice.**apache.org<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
