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:26:27 GMT
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