openoffice-l10n mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan iversen <jancasacon...@gmail.com>
Subject Re: OpenOffice localization tasks
Date Fri, 12 Oct 2012 11:06:17 GMT
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 <jogischmidt@gmail.com> 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 <jogischmidt@gmail.com> 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 <jogischmidt@gmail.com>
> wrote:
> >>>
> >>>> On 10/11/12 7:05 PM, Alexandro Colorado wrote:
> >>>>> On 10/11/12, Michael Bauer <fios@akerbeltz.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message