I got the same idea so I am right now downloading the complete ooo in my ubuntu server and then I can start the process of getting to compile.
But I agree with you, it is better that I have my own playground, and then as I get results check with you. jan On 12 October 2012 13:55, Jürgen Schmidt <[email protected]> wrote: > On 10/12/12 1:34 PM, jan iversen wrote: > > I will give a go next week. > > > > A question is it easy for you to start the generation process ? > > > > I was thinking of changing localize.cpp so it generates a log file (e.g. > > /tmp/jan.log). If you run the generation process with this new > executable, > > I would get information about which exact parameters is used in the > > process, this is a lot easier than looking through all makefiles and > > scripts. > > sure I can do that but you can also do that on your own when you have a > build env for the office. This is probably a good idea anyway if you > plan to work on the sources. > > See http://wiki.openoffice.org/wiki/Localization_for_developers > > You simply can run "localize -e -l en-US -f foo.sdf" in the main > directory when you have configured a working build env. > > But this process should be also improved over time and triggered via a > special target in the makefile. And where the resource files have to be > specified explicitly. Currently the process iterates recursively over > the complete source tree and collect all files with known extensions. > This includes partly files that don't have to be translated, eg. sample > files in the SDK. The current process used flag files to mark a > directory not translation relevant. > > I think it would better to have well defined targets for it. But also a > minor detail that can be changed later as well. > > > > > I too am not sure how the po files should be generated, I kind of like > the > > granularity they have today, because it makes team work easier. But as > you > > say that is a minor detail. > > > > My question about sdf might have been weak. > > > > I understood the roundtrip and agree with that. > > > > It's a round trip > > resource files -> sdf -> po -> sdf -> resources > > > > Better would be > > resource files -> po -> resources > > > > But I am unsure it the roundtrip today is: > > resource files -> sdf -> po -> sdf -> resources > > -> XXXX > > > > meaning that some other script uses the sdf file for another purpose. > > no, I don't think so > > Juergen > > > > > > On 12 October 2012 13:26, Jürgen Schmidt <[email protected]> wrote: > > > >> On 10/12/12 1:06 PM, jan iversen wrote: > >>> with svn support in pootle I am convinced it would be beneficial to > keep > >>> the po files. > >>> > >>> I agree with the point of keeping the actual development slim and not > >>> depending on too much else, but with my proposal the development will > be > >> a > >>> supplier to the po "project" just like the translators, and thereby we > >> have > >>> the 2 processes totally decoupled. > >>> > >>> As far as I can see, if we change the l10tools we are done in a first > >> step, > >>> then in a second step we can take the po and store in svn together with > >>> starting the pootle server. > >>> > >>> If you are prepared to go down that route, I could change part of the > >> tools > >>> next week and you could try to generate po files instead of sdf files ? > >> > >> If you time and interest to do that, it would be perfect. It's the first > >> step going in the right direction. The question is how fine grained we > >> generate the po files. > >> We can either create one po for any resource file or can combine several > >> resource files in a directory in one po file. similar to the split from > >> the sdf into po files. I am not sure and it is probably a detail only. > >> > >>> > >>> Can you crosscheck with the total build process that the sdf file is > >> unused > >>> (apart from po file generation) ? > >> > >> I am not sure if I understand you correct. The sdf files under > >> extras/l10n are essential and contains the localization for the whole > >> office. > >> > >> It's a round trip > >> resource files -> sdf -> po -> sdf -> resources > >> > >> Better would be > >> resource files -> po -> resources > >> > >> Juergen > >> > >> > >>> > >>> jan I. > >>> > >>> On 12 October 2012 12:56, Jürgen Schmidt <[email protected]> > wrote: > >>> > >>>> On 10/12/12 11:50 AM, jan iversen wrote: > >>>>> I know the feeling of inheriting software and procedures, that is not > >>>>> always easy...but also a possibility to clean up. In my experience > when > >>>> you > >>>>> have responsibility for a procedure over a very long time, it tends > to > >> be > >>>>> difficult to change it. > >>>>> > >>>>> I had a look at the translation table and they are mostly standard > >>>>> programs, that can pretty easy be adapted, no big deal. You must be > >> using > >>>>> other programs to: > >>>>> a) split sdf file to po files > >>>> > >>>> oo2po from the translation toolkit > >>>> > >>>>> b) collect po files to sdf file > >>>> > >>>> po2oo from the translation toolkit > >>>> > >>>>> c) generate release tree files from sdf file > >>>> > >>>> sdf files are checked in under extras. The idea was to separate the > >>>> localization from the main source trunk for normal development work to > >>>> keep it smaller and faster. > >>>> > >>>>> or have I overlooked a feature in the source ? > >>>>> > >>>>> It is true that in old days sun had a proprietary tool (I know it > from > >>>> the > >>>>> UNIX line) and I think it is a safe assumption that it worked with > sdf > >>>>> files. > >>>>> > >>>>> You are right my proposal is no revulotion merely an evolution :-) > >>>>> > >>>>> However there is a big difference, today you throw away the po files > >> and > >>>>> generate them new everytime, because the projects files are > considered > >>>> the > >>>>> originals. Doing this means that translators cannot keep information > >>>>> easily. Secondly in my proposal I get rid of the sdf file, which > seems > >> to > >>>>> be a real unnecessary step. > >>>>> > >>>>> Having the po files in a source control system, will also make it a > lot > >>>>> easier to determine changes in the translated part, also during > >>>>> translation. Today you only store versions of the regenerated release > >>>> tree > >>>>> files. If the translators works with source control, it is also a lot > >>>>> easier to check if files have been proofread/reviewed and compare > >>>> changes. > >>>> > >>>> Pootle support svn directly and probably the po files could be stored > in > >>>> svn directly. > >>>> > >>>> Juergen > >>>> > >>>>> > >>>>> I could be fun to try it on a small scale like e.g. convert > >> localize.cxx > >>>> to > >>>>> generate a po file. > >>>>> > >>>>> > >>>>> > >>>>> On 12 October 2012 11:32, Jürgen Schmidt <[email protected]> > >> wrote: > >>>>> > >>>>>> On 10/12/12 10:46 AM, jan iversen wrote: > >>>>>>> I agree with you at the end of day we need to have a working > solution > >>>> and > >>>>>>> that can then over time evolve. > >>>>>>> > >>>>>>> I have a couple of questions about the process: > >>>>>>> > >>>>>>> 1) how many (rough number) conversion/extract programs do you have > ? > >>>>>> > >>>>>> DISCLAIMER: I was not responsible for this before ;-) > >>>>>> > >>>>>> In > >>>>>> > >>>>>> > >>>> > >> > http://svn.apache.org/viewvc/incubator/ooo/trunk/main/l10ntools/source/localize.cxx?view=markup > >>>>>> > >>>>>> starting line 49 you can see the extensions of files that can > contain > >>>>>> localization strings. The second column lists the used tool to > extract > >>>>>> from these files. > >>>>>> > >>>>>> It seems that we have 9 tools whereas one tool get called with > >> different > >>>>>> options on different extensions. > >>>>>> > >>>>>>> 2) is the sdf file used solely as an intermediary file to create > the > >>>> .po > >>>>>>> files and create the language files used in the different release > >>>> trees ? > >>>>>> > >>>>>> Yes, I think so. But I can't say for sure, I think the sdf file was > >> used > >>>>>> in the past Sun internally to do the translation, probably with > >>>>>> proprietary tools as well. Later it was extended to use Pootle to > >>>>>> improve the collaboration with the community. > >>>>>> > >>>>>>> > >>>>>>> I am just thinking about a process like this ? > >>>>>>> > >>>>>>> -- have a database (or file storage) with all po files for all > >>>> languages, > >>>>>>> INCLUDING one EN-EN, this is the repository. which should be kept > >> under > >>>>>>> source control. > >>>>>>> > >>>>>>> When a new release is made go through the following steps: > >>>>>>> a) convert the release tree files to one PO file EN-EN (this would > >>>> need a > >>>>>>> change of the current extract programs) > >>>>>>> b) compare the new EN-EN PO file to the existing EN-EN PO file, and > >>>>>> create > >>>>>>> a delta file (With source control this is quite easy) > >>>>>>> c) update/merge the language EN-XX PO files according to the delta > >>>> file. > >>>>>>> (this is a simple modified merge in the source control) > >>>>>>> > >>>>>>> d) get the changed language files translated, e.g. through the > pootle > >>>>>> server > >>>>>>> > >>>>>>> e) convert the translated EN-XX PO files back to the release files > >>>> (this > >>>>>>> would need a change of the current convert programs). > >>>>>>> > >>>>>>> I think you avoid many problems by defining the project (release > >> tree) > >>>>>>> files as generated files and not as original files. > >>>>>> > >>>>>> isn't it very similar to the process today? Ok we have the sdf > >>>>>> conversion step as additional step but the rest seems to be similar. > >>>>>> > >>>>>> When we have new string to localize, a new sdf files is create and > >>>>>> converted to template files for Pootle. The related Pootle project > >> gets > >>>>>> updated and merged with the new templates. The result is a not > >> complete > >>>>>> translated project with the missing delta. This delta gets > translated > >>>>>> and the result get converted back in sdf. > >>>>>> > >>>>>> Pootle works internally with a database and the po files gets > synched > >>>>>> into the database and back. > >>>>>> > >>>>>> In pootle you can easy navigate to the untranslated strings and I > hope > >>>>>> offline tools allow this as well. > >>>>>> > >>>>>> In the end we would benefit from getting rid of the sdf files > because > >> it > >>>>>> is one unnecessary conversion step where errors can happen. > >>>>>> > >>>>>> Juergen > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 12 October 2012 10:03, Jürgen Schmidt <[email protected]> > >>>> wrote: > >>>>>>> > >>>>>>>> On 10/11/12 7:05 PM, Alexandro Colorado wrote: > >>>>>>>>> On 10/11/12, Michael Bauer <[email protected]> wrote: > >>>>>>>>>> The latest versions of Pootle have a feature called AmaGama > which > >>>> acts > >>>>>>>>>> as a cross-OS translation memory. For offline, there's Virtaal. > >>>>>> Perhaps > >>>>>>>>>> not ideal for mainstream translation work like newsletters and > >>>> novels > >>>>>>>>>> etc but I've found it very efficient for software localization. > >>>>>>>>>> > >>>>>>>>>> Michael > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> I like Lokalize for KDE, the shortcuts and different layout makes > >> me > >>>>>>>>> work faster on switching from one string to the next. Also has > good > >>>>>>>>> TM. > >>>>>>>> > >>>>>>>> We can talk a lot about a new tooling or new format but in the end > >> the > >>>>>>>> work have to be done and it is far more complex when you analyze > >> what > >>>> we > >>>>>>>> have and use in the code. > >>>>>>>> > >>>>>>>> We collect translation strings from various different formats and > >>>> create > >>>>>>>> one big sdf file (en-US) which is used as template for all other > >>>>>>>> languages. We convert and split the one big sdf in many pot files. > >>>> After > >>>>>>>> translation the po files are converted back into one big sdf file > >> for > >>>>>>>> each language. Several different tools extract the strings from > the > >>>> sdf > >>>>>>>> file and create the final target files that can be used in build > >> (xcu, > >>>>>>>> property files, help files, ...) > >>>>>>>> > >>>>>>>> Juergen > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > -- Jan Iversen ________________________________________________ Tel. no. +34 622 87 66 19 jandorte.wordpress.com
