openoffice-l10n mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@gmail.com>
Subject Re: OpenOffice localization tasks
Date Fri, 12 Oct 2012 11:55:59 GMT
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 <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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 


Mime
View raw message