On 5 September 2013 08:14, Jürgen Schmidt <jogischm...@gmail.com> wrote:
> On 9/4/13 6:53 PM, janI wrote: > > On 4 September 2013 18:13, Jürgen Schmidt <jogischm...@gmail.com> wrote: > > > >> 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. > >> > >> > > I was not aware that we have different options (I as the developer do not > > see these options), its really very late for that discussion. The > workflow > > is not up for discussion, we had that discussion based on my wiki pages > > before I started programming and after several changes due to comments we > > had lazy consensus. > > I remember at least one chat with you where I mentioned that I would not > move the po files in main directly. But because the fact that it is only > an implementation detail (for me) where these files are I don't spent > further time on it. > Correct you are the direct reason, I made main/langauges instead of what the original main/l10ntools/languages. We did also agree that is was ok to do it like that. > > > > > > > > > > >> 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. > >> > > > > Changes in the .po will not be able to break a en-US build, but might > break > > a language build. I do however not see the difference between: > > if that will be the final result and workflow we will be all happy. > Maybe we don't see it yet because our build process today is far away > from this. > If you read the sentence with .sdf instead of .po is valid today, no need to wait for the future. > > a) I as a developer introduces a build-breaker in the source (will most > > likely also hit en-US build) > > or > > b) I as a translator introduces a translation that is a build breaker for > > that language (not en-US, nor other languages) > > In general I agree with the minor difference that a developer can > immediately fix the problem. A strange problem within help files takes > probably longer or at least I don't see that it will be fixed in the > same way. > I like that, remember 4.0 I made a build breaker as a developer, it took 3 month before it was identified and repaired. With .po files it will be a lot easier, for the one who runs build --with-language to correct the problem. > > > > In my mindset, translator==developer, just with different tools. I sense > > you see it differently. > > No I don't see a difference here, especially if a translator would build > the lang version and did the tests immediately. But we know that this is > not possible. Not today and not tomorrow with a much more simplified > build env. > I actually see that differently, with .po files we could (and should) do a nightly build with languages, which would allow translators to test within 24 hours. > > > > > 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 ... > >> > > > > Yes it can, we can f.x. just take the LO way (using the old tools, just > > generating po files instead of sdf files), > > well I think we agreed indeed that we need something better and I don't > see your point. > my point was simple, that there are many workflows possible, one of them could be doiing like LO does. > > > > > I actually gave you one example why its a bad idea not to have it > > integrated (different versions in extras and main or a non-existing > extras). > > I don't get your point here > Np, I see a huge problem having 2 integrated parts (.po files and sources) in 2 different svn tree paths, and dont know how I can be sure they are at same level. Example: you run "build --genPO" and extras is not updated, this can result in template changes, which then goes to pootle, giving .po file changes in all langauges. Not a nice situation. Example: you run "build --all --with-language" and extras is not updated, the generated binary does not contain the newest language changes, and the translator (unaware of this), spent time trying to understand why the translation misbehaives. > > > > > Other workflows can for sure be implemented and will most likely work, > the > > only but is, you have to come up with a volunteer that wants to do it. > > It looks to me that you either don't want to see my point or that you > are not interested in other opinions. Either we do it in your way or you > don't work longer on it. Mmmh > You can look at it like that, you dont to realize, that this is developed, integrated in the build system (which was a huge task), so I am here being asked to throw away part of what I made and redo it. Before I started this development, we had a discussion on how to do it, that was the time where we had all the options we wanted, not when development is finished, its not fair to ask for that kind of changes. I take you "Mmmh" as an interesting comment, I am a volunteer and do this because it interests me, I dont use my spare time on things that do not interest me. But I do get your point, and admit my way of working (discuss BEFORE implementation, and only implement once). rgds jan I. > We agree in nearly every point and I of course don't understand you. We > simply mentioned that we would store the po files in a separate > directory, nothing more and nothing less. > > I hope you don't think that I am against your work or your proposal. > Quite the contrary I am a strong supporter of it and I am happy that you > are interested to work on this of course not easy task. > > > I am probably not able to follow your work in all technical details but > I am interested in the result and as I promised I will build your branch > on Mac. > > Juergen > > > > > rgds > > jan I. > > > > > >> > >> 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 > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
