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:34:39 GMT
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.

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.

On 12 October 2012 13:26, Jürgen Schmidt <jogischmidt@gmail.com> 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 <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