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 ? Can you crosscheck with the total build process that the sdf file is unused (apart from po file generation) ? 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
