openoffice-l10n mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandro Colorado <...@oooes.org>
Subject Re: OpenOffice localization tasks
Date Thu, 11 Oct 2012 16:32:10 GMT
On 10/11/12, J├╝rgen Schmidt <jogischmidt@gmail.com> wrote:
> On 10/11/12 5:14 PM, jan iversen wrote:
>> From the description it looks a lot better that POedit. I installed
>> poedit
>> because I got a mail from andrea saying so :-)
>>
>> As far as I can see OmegaT is very useful for new translations, however
>> it
>> does not seem to have a feature that can control existing translations.
>>
>> Doing the danish translation, I have come across a couple of words that
>> are
>> today translated differently. So I was looking at a tool that controlled
>> the translation.
>>
>> Anyhow I will try to use OmegaT for translating the help content, which
>> is
>> due this evening.
>>
>> A pootle server has a form of cloud memory, where every translator can be
>> given rights (read/write) and I think that would do the job.
>
> yes, the problem is that users have to be committer at Apache ;-) It
> always helps if we volunteers start to work offline first and become
> committer over time. Not optimal but working for now and many people
> prefer offline translation anyway. But it could improve the
> collaboration by downloading only a single po file, translate and upload
> it again.
>
> There is a lot of room for improvements and any good idea to improve the
> whole process is welcome.
>
> I would like to see a completely new tooling to get rid of the sdf files
> that we use in the build and use po files directly. One from my

Oh yes, I remember some format wars on this regard, what ever happened
to XLIFF, wouldnt this be 'easier' since is XML-to-XML formating as
opposed of POT (plain ol text) to XML?

> perspective unnecessary conversion step could be eliminated this way.
> But there is more work to do here and many tools who extract the strings
> from sdf have to be changed (xcu files, java property files, help files,
> resource files, ...). Real programming work would be necessary and a lot
> of evaluating how exactly the current process works. But Andre has
> already figured out that a lot unnecessary copying is done here during
> the build process and that there is a lot of room for improvements.
> Volunteers are welcome ;-)
>
> Juergen
>
>
>>
>>
>> Jan I.
>>
>> On 11 October 2012 16:42, Alexandro Colorado <jza@oooes.org> wrote:
>>
>>> Well there is the translation memory used in OmegaT which is one of
>>> the most revered programs. PoEdit has some translation memory support.
>>> http://www.omegat.org/en/omegat.html
>>>
>>> I wonder if there is a way of having a cloud translation memory that
>>> can be shared and used between the whole team. That will allow
>>> translators to get their terminology on the same vein.
>>>
>>> This could be done maybe even if there were cloud po editors. Pootle
>>> editor does use some TM, but is also pretty poorly implemented. Some
>>> UX improvements could go a long way.
>>>
>>> Other things to keep in mind are nemonics and reserved functions like
>>> Spreadsheet formulas.
>>>
>>>
>>> On 10/11/12, jan iversen <jancasacondor@gmail.com> wrote:
>>>> Hi.
>>>>
>>>> I think I have used it back in the days where sun made a PC version of
>>>> unix, if that could be made available it could really enhance quality
>>>> of
>>>> the translation.
>>>>
>>>> I am right now looking into making a small program that checks for this
>>>> kind of translation mishaps. I have tried POconsistency which is nice,
>>> but
>>>> does not control glossary strongly enough.
>>>>
>>>> The one I worked with, had a lot of languages (at least all the western
>>>> ones).
>>>>
>>>> rgds
>>>> Jan I
>>>>
>>>> On 11 October 2012 15:54, Alexandro Colorado <jza@oooes.org> wrote:
>>>>
>>>>> Back in the Sun days we used to have a Glossary that spread throughout
>>>>> all products explaining the terminology on different language. It was
>>>>> like an OpenGrok for terms.
>>>>>
>>>>> Also a style guide, which I guess we still do, is only a matter of
>>>>> making available to translators.
>>>>>
>>>>> On 10/11/12, jan iversen <jancasacondor@gmail.com> wrote:
>>>>>> HI.
>>>>>>
>>>>>> I would be a good idea to have a glossary.po file for each language,
>>>>>> even
>>>>>> though the program does not use it. It is important that the
>>>>>> translations
>>>>>> are consistent (e.g. edit is translated identically throughout all
>>>>> files).
>>>>>>
>>>>>> I would also like to have a consistency check, that automatically
>>>>>> checks
>>>>>> accelerators and words are translated identically. I have been
>>>>>> playing
>>>>> with
>>>>>> poconsistency which does quite a nice work.
>>>>>>
>>>>>> The idea of having spreadsheets to control sorting etc. is brillant.
>>>>>> I
>>>>> used
>>>>>> to have documents as well to check the functionality of the
>>> dictionary.
>>>>>>
>>>>>> have a nice day
>>>>>> rgds
>>>>>> Jan
>>>>>>
>>>>>> On 10 October 2012 23:57, Rob Weir <robweir@apache.org> wrote:
>>>>>>
>>>>>>> Does this make sense as a general list of tasks for fully localizing
>>>>>>> OpenOffice for a language?
>>>>>>>
>>>>>>> 1. Translate UI strings in Pootle
>>>>>>>
>>>>>>> 2. Verify translations in a snapshot build of OpenOffice
>>>>>>>
>>>>>>> 3. Verify bundling of correct dictionaries
>>>>>>>
>>>>>>> 4. Verify other areas of localization:  sorting, number formatting,
>>>>>>> date formatting, string comparisons.   Anything else?  Should
we
>>>>>>> have
>>>>>>> some standard test spreadsheets and other documents to help verify
>>>>>>> these areas?
>>>>>>>
>>>>>>> 5. Translate help strings.
>>>>>>>
>>>>>>> 6. Help update/maintain native language website, e.g.,
>>>>>>> www.openoffice.org/de, etc.
>>>>>>>
>>>>>>> 7. Help translate release announcements, release notes and other
>>>>>>> materials that help promote the new release
>>>>>>>
>>>>>>> Any thing else?
>>>>>>>
>>>>>>> Some languages do only 1-4, which is probably the minimum that
will
>>>>>>> give a good user experience.  Some languages are enabled for
5-7 as
>>>>>>> well.  In areas where we have multiple volunteers this might
be one
>>>>>>> way of splitting up the effort.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> -Rob
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jan Iversen
>>>>>> ________________________________________________
>>>>>> Tel. no. +34 622 87 66 19
>>>>>> jandorte.wordpress.com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Alexandro Colorado
>>>>> PPMC Apache OpenOffice
>>>>> http://es.openoffice.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Jan Iversen
>>>> ________________________________________________
>>>> Tel. no. +34 622 87 66 19
>>>> jandorte.wordpress.com
>>>>
>>>
>>>
>>> --
>>> Alexandro Colorado
>>> PPMC Apache OpenOffice
>>> http://es.openoffice.org
>>>
>>
>>
>>
>
>


-- 
Alexandro Colorado
PPMC Apache OpenOffice
http://es.openoffice.org

Mime
View raw message