[Fwd: Re: L10n tool]

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Fwd: Re: L10n tool]

Sabine Cretella
I forgot: it is already used for OpenOffice.org localisation.

-------- Original Message --------

Hi, did you ever check out OmegaT? It can already localise java .bundle
files, works great with html, xhtml, all kinds of OpenOffice.org formats
etc.

It already has a Translation Memory system and in a second stage is
going to be connected to Ultimate Wiktionary through a reference
implementation in order to directly access the glossaries there.
(Ultimate Wiktionary is a further development of Wiktionary).

If you want to know more about this, just let me know.

Best wishes,

Sabine

****
Sabine Cretella
[hidden email]
skype: sabinecretella


Ricardo Palomares Martinez wrote:

>Zbigniew Braniecki escribió:
>  
>
>>Hi all.
>>I'm developing a L10n tool that should be the ultimate answer to all
>>problems with localization of Mozilla based projects.
>>    
>>
>
>
>Funny, I've just agreed to do my final year project which will
>hopefully be a *Java* l10n tool for Mozilla based projects (and maybe
>others in the future).
>
>My idea is to take the concepts (not the code) on Mozilla Translator
>and go beyond. It will undoubtedly take me more time to complete than
>you, though (but I *have* to do it, because otherwise I won't get
>degree, and I have to do it by myself, so I can't receive any help).
>
>So, maybe in a year two functional tools will be available when no one
>is ready right now.
>  
>



       

       
               
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Dwayne Bailey
On Thu, 2005-11-10 at 07:49 +0100, Sabine Cretella wrote:
> I forgot: it is already used for OpenOffice.org localisation.

Just to clarify.  Its used IIRC for .sxw and .od* files.  It isn't used
for l10n of the interface, unless its learnt PO since last I looked.

--
Dwayne Bailey
Translate.org.za

+27-12-460-1095 (w)
+27-83-443-7114 (cell)

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Sabine Cretella

>>I forgot: it is already used for OpenOffice.org localisation.
>>    
>>
>
>Just to clarify.  Its used IIRC for .sxw and .od* files.  It isn't used
>for l10n of the interface, unless its learnt PO since last I looked.
>  
>
How does the file to be translated look like before it is converted to
.po files?

There are also OpenSource XLIFF editors and there are already XLIFF
conversion tools for .po files around.

Sorry, I am not a programmer, but just a localiser working with very
different sourcecode files (c++, java etc.) it could well be that
there's no conversion to .po necessary.

Ciao, Sabine



       

       
               
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Dwayne Bailey
On Thu, 2005-11-10 at 12:33 +0100, Sabine Cretella wrote:

> >>I forgot: it is already used for OpenOffice.org localisation.
> >>    
> >>
> >
> >Just to clarify.  Its used IIRC for .sxw and .od* files.  It isn't used
> >for l10n of the interface, unless its learnt PO since last I looked.
> >  
> >
> How does the file to be translated look like before it is converted to
> .po files?

OpenOffice uses an internal format called GSI or SDF.  Its essentially a
tab delimeted flat file of all translations.  The translate toolkit
unbundles that to PO format.  Which is what most teams doing GUI
translation are using.

> There are also OpenSource XLIFF editors and there are already XLIFF
> conversion tools for .po files around.

Yes there are and they're gaining functionality.  PO will I hope someday
be replaced by XLIFF.

> Sorry, I am not a programmer, but just a localiser working with very
> different sourcecode files (c++, java etc.) it could well be that
> there's no conversion to .po necessary.

For OOo?  Nope the base format is maddening!  

Although I'd class Mozilla's disparate files as worse for localisation.
Im Mozilla we still have configuration in translations files, we have 2
different file formats doing weird things like requiring escaped Unicode
(great for Latin languages a nightmare for anyone else), we have a
random selection of how to represent accesskeys, we have a handful of
other files that need localisation.  In fact I'm always amazed at how
much l10n actually gets done.  

We must be a dedicated bunch.  Either that or masochists :)

--
Dwayne Bailey
Translate.org.za

+27-12-460-1095 (w)
+27-83-443-7114 (cell)

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Axel Hecht
In reply to this post by Sabine Cretella
Dwayne Bailey wrote:

> On Thu, 2005-11-10 at 12:33 +0100, Sabine Cretella wrote:
>>>> I forgot: it is already used for OpenOffice.org localisation.
>>>>    
>>>>
>>> Just to clarify.  Its used IIRC for .sxw and .od* files.  It isn't used
>>> for l10n of the interface, unless its learnt PO since last I looked.
>>>  
>>>
>> How does the file to be translated look like before it is converted to
>> .po files?
>
> OpenOffice uses an internal format called GSI or SDF.  Its essentially a
> tab delimeted flat file of all translations.  The translate toolkit
> unbundles that to PO format.  Which is what most teams doing GUI
> translation are using.
>
>> There are also OpenSource XLIFF editors and there are already XLIFF
>> conversion tools for .po files around.
>
> Yes there are and they're gaining functionality.  PO will I hope someday
> be replaced by XLIFF.

In any environment that is slightly similar to mozilla, that is, cvs
based with separate repositories for en-US and other locales, this is
not going to fly. Nobody is going to merge the changes in the en-US
files into xliff. I'm not sure if xliff does anything about parameters
in localized strings, but from what I can tell from the three pages I
glanced at it's seriously over-engineered.

>> Sorry, I am not a programmer, but just a localiser working with very
>> different sourcecode files (c++, java etc.) it could well be that
>> there's no conversion to .po necessary.
>
> For OOo?  Nope the base format is maddening!  
>
> Although I'd class Mozilla's disparate files as worse for localisation.
> Im Mozilla we still have configuration in translations files, we have 2
> different file formats doing weird things like requiring escaped Unicode
> (great for Latin languages a nightmare for anyone else), we have a
> random selection of how to represent accesskeys, we have a handful of
> other files that need localisation.  In fact I'm always amazed at how
> much l10n actually gets done.  

Well, there are two conceptually different requirements in our
localization story. The first one is to easily insert replaced content
into XML. If there are better ways than DTDs, I'd be glad to hear about
them.
The other one is parameters in localizable strings. DTDs don't offer
that (at least not printf friendly), properties do.
The encoding story with property files is a sad one, yes. Any decent
editor for property files should work around that, though. Not that I
know of any, of course.

> We must be a dedicated bunch.  Either that or masochists :)

It's an overall compromise. We have lots of l10n teams out there, but
there are still more coders on the UI part or core, that are happily
using two rather easy techniques, where each of them fits best.

And yes, I don't know anybody in the FOSS enviroment that is not really
dedicated.

Axel
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Ognyan Kulev
Axel Hecht wrote:
> Well, there are two conceptually different requirements in our
> localization story. The first one is to easily insert replaced content
> into XML. If there are better ways than DTDs, I'd be glad to hear about
> them.

Is it possible to run XSLT transformation before rendering XML file in
XUL UI?

Regards,
ogi
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Rod Whiteley
In reply to this post by Dwayne Bailey
Sabine Cretella wrote:
> ...I am not a programmer, but just a localiser working with very
> different sourcecode files...

Could OmegaT be used to translate Mozilla interfaces?  Would it have
advantages?  If it's just a matter of file formats, there are
programmers here...

--
Rod Whiteley
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Giacomo Magnini
Rod Whiteley wrote:
> Sabine Cretella wrote:
>> ...I am not a programmer, but just a localiser working with very
>> different sourcecode files...
>
> Could OmegaT be used to translate Mozilla interfaces?

Currently not, but could be used, yes. It can already handle (X)HTML
files, so it may be already used for translating docs/help pages.
The real pain is that it doesn't like getting already translated files,
so you basically have to start from scratch using cut & paste for ages...

> Would it have advantages?

One above all of the others: a unified Translation Memory(*), so you can
use exactly the same wording for every product (FX, TB, SM, SB, you name
it) that can be shared among different translators and updated by all at
the same time. So if you modify a term, the term will be updated
everywhere in the translation, across all products.
Btw, the program can suggest an automatic translation orders of
magnitude better than MT ever will...

> If it's just a matter of file formats, there are
> programmers here...

Well, OmegaT uses single lines or phrases as a base for the translation:
this can be mapped into using single entities in Mozilla files. In some
way, OmegaT already handles .properties files (as used in Java), so it's
a start.
The real problem would be the management of accesskeys and their
bindings to the entities.
Not sure about OmegaT handling of the Win/UTF mess Mozilla is using, but
since it already does support at least Japanese and Russian, I see few
problems here.
Adding po support, xpi writing and cvs support would be the next steps.
I think you can stretch OmegaT in doing those things, but I don't think
it would be OmegaT anymore...
All you need to start working on the source is getting it and fire
NetBeans up: it will compile and run in a few minutes (NB 5.0b and JDK
1.5.x are fine, I can swear! ;) Even if they produce larger classes than
1.4.x).
Ciao, Giacomo.

(*) The format of the Translation Memory used by OmegaT is sort of a
standard in the professional translators' world, so it can be used (and
improved!) by professional translators using their specialized tools
(and their already huge and mature Translation Memory).
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Sabine Cretella
Giacomo Magnini wrote:

> Rod Whiteley wrote:
>
>> Sabine Cretella wrote:
>>
>>> ...I am not a programmer, but just a localiser working with very
>>> different sourcecode files...
>>
>>
>> Could OmegaT be used to translate Mozilla interfaces?
>
>
> Currently not, but could be used, yes. It can already handle (X)HTML
> files, so it may be already used for translating docs/help pages.
> The real pain is that it doesn't like getting already translated
> files, so you basically have to start from scratch using cut & paste
> for ages...

there is an alignment tool ... and you can create a tmx file that is
readable for OmegaT by using a free tool from maxprograms.com (don't
remember the exact name of the tool now) - this would allow to re-use
.po files since these could be transformed into a table.

>
>> Would it have advantages?
>
>
> One above all of the others: a unified Translation Memory(*), so you
> can use exactly the same wording for every product (FX, TB, SM, SB,
> you name it) that can be shared among different translators and
> updated by all at the same time. So if you modify a term, the term
> will be updated everywhere in the translation, across all products.
> Btw, the program can suggest an automatic translation orders of
> magnitude better than MT ever will...

:-) I fully agree

>
>> If it's just a matter of file formats, there are programmers here...
>
>
> Well, OmegaT uses single lines or phrases as a base for the
> translation: this can be mapped into using single entities in Mozilla
> files. In some way, OmegaT already handles .properties files (as used
> in Java), so it's a start.
> The real problem would be the management of accesskeys and their
> bindings to the entities.
> Not sure about OmegaT handling of the Win/UTF mess Mozilla is using,
> but since it already does support at least Japanese and Russian, I see
> few problems here.
> Adding po support, xpi writing and cvs support would be the next steps.
> I think you can stretch OmegaT in doing those things, but I don't
> think it would be OmegaT anymore...
> All you need to start working on the source is getting it and fire
> NetBeans up: it will compile and run in a few minutes (NB 5.0b and JDK
> 1.5.x are fine, I can swear! ;) Even if they produce larger classes
> than 1.4.x).

1.6 RC2 is already out :-)

Well: OmegaT should become a tool that can be used for many applications
and having more people use it means having more people interested in it.
It means that there will be further needs and this will lead to further
development that in the end is a real advantage for all.

I just noted that my other answers did not go to the list - they will
follow in a minute.

Ciao, Sabine

       

       
               
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Axel Hecht
In reply to this post by Axel Hecht
Ognyan Kulev wrote:
> Axel Hecht wrote:
>> Well, there are two conceptually different requirements in our
>> localization story. The first one is to easily insert replaced content
>> into XML. If there are better ways than DTDs, I'd be glad to hear
>> about them.
>
> Is it possible to run XSLT transformation before rendering XML file in
> XUL UI?

If you want to cripple performance to a death, sure.

XSLT is a *HUGE* overkill for such a task.

Axel
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Ognyan Kulev
Axel Hecht wrote:
> If you want to cripple performance to a death, sure.
>
> XSLT is a *HUGE* overkill for such a task.

In this direction (transform before interpet), two things can be done to
improve performance:

* Specialized transformation just for the l10n case
* Caching (in browser cache?) of transformed xml:s.

Regards,
ogi
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: OmegaT [was L10n tool]

Rod Whiteley
In reply to this post by Giacomo Magnini
Giacomo Magnini wrote:
> ...[OmegaT] can already handle (X)HTML files...

> ...it doesn't like getting already translated files...

> The real problem would be the management of accesskeys and their
> bindings to the entities...

> Adding po support, xpi writing and cvs support would be the next steps.
> I think you can stretch OmegaT in doing those things, but I don't think
> it would be OmegaT anymore...

I agree.

> All you need to start working on the source is getting it...

I got the source, and I can sort of see how to make a filter for a new
file type, but I'm not sure that I want to become an OmegaT developer.
The requirements are specific to Mozilla.  So I think perhaps the
solution should be in the Mozilla environment.

I'm thinking of a new tool that reads Mozilla source code and writes it
in formats that OmegaT can use.  For example, when it reads .dtd it
writes .properties.  When it reads an existing translation it writes a
translation memory.

Then, after the translation is done it reads OmegaT's target files and
writes them back as Mozilla source.  When it writes them back, it also
provides a way for you to assign access keys.

This is only for localization.  It does not access CVS, make XPIs, etc.

If I wrote a tool like that, would anyone use it?

--
Rod Whiteley
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: OmegaT [was L10n tool]

Sabine Cretella

>
> I got the source, and I can sort of see how to make a filter for a new
> file type, but I'm not sure that I want to become an OmegaT developer.
> The requirements are specific to Mozilla.  So I think perhaps the
> solution should be in the Mozilla environment.
>
> I'm thinking of a new tool that reads Mozilla source code and writes
> it in formats that OmegaT can use.  For example, when it reads .dtd it
> writes .properties.  When it reads an existing translation it writes a
> translation memory.
>
> Then, after the translation is done it reads OmegaT's target files and
> writes them back as Mozilla source.  When it writes them back, it also
> provides a way for you to assign access keys.
>
> This is only for localization.  It does not access CVS, make XPIs, etc.
>
> If I wrote a tool like that, would anyone use it?
>
Hi,

I think this makes sense - of course I suppose it would not even be a
problem to have a Mozilla specific filter within OmegaT, but this is
something Maxym can tell you better than me. Well, if localisers have
.bundle files to work with, there's no doubt that this is then going to
be quite easy for us or better: for translators (I don't know when I
will have time to actively participate in localisation).

Maybe converting to .bundle and backwards to .dtd is easier to program
than creating the filter itself. Hmmm ... well this is your decision :-)

In any case: having a TM of the GUI and then translating help files or
other documentation will also help to maintain the correct terminology
since you can search within the TMs to see how the term was translated
in the GUI and you can create a glossary that automatically shows you
which terms are used.

Well it would be great to see this happen :-)

Best wishes,

Sabine

       

       
               
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: OmegaT [was L10n tool]

davidf (Bugzilla)
In reply to this post by Rod Whiteley
Rod Whiteley wrote:

> Giacomo Magnini wrote:
>
>> ...[OmegaT] can already handle (X)HTML files...
>
>
>> ...it doesn't like getting already translated files...
>
>
>> The real problem would be the management of accesskeys and their
>> bindings to the entities...
>
>
>> Adding po support, xpi writing and cvs support would be the next steps.
>> I think you can stretch OmegaT in doing those things, but I don't
>> think it would be OmegaT anymore...
>
>
> I agree.
>
>> All you need to start working on the source is getting it...
>
>
> I got the source, and I can sort of see how to make a filter for a new
> file type, but I'm not sure that I want to become an OmegaT developer.
> The requirements are specific to Mozilla.  So I think perhaps the
> solution should be in the Mozilla environment.
>
> I'm thinking of a new tool that reads Mozilla source code and writes
> it in formats that OmegaT can use.  For example, when it reads .dtd it
> writes .properties.  When it reads an existing translation it writes a
> translation memory.
>
> Then, after the translation is done it reads OmegaT's target files and
> writes them back as Mozilla source.  When it writes them back, it also
> provides a way for you to assign access keys.
>
> This is only for localization.  It does not access CVS, make XPIs, etc.
>
> If I wrote a tool like that, would anyone use it?
>
This seems a bit crazy to me. Why not rather use the translate toolkit
to convert things to .PO format and then get OmegaT to understand PO
format. That way you should be able to take advantage of different
translations, and use OmegaT for OpenOffice.org using PO files and other
PO-based projects as well...
Trust me, I've done lots of writing converters for the translate toolkit
and to get the thing totally right is a fair bit of work, so I think its
best to use existing work

David
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: OmegaT [was L10n tool]

Sabine Cretella

>>
> This seems a bit crazy to me. Why not rather use the translate toolkit
> to convert things to .PO format and then get OmegaT to understand PO
> format. That way you should be able to take advantage of different
> translations, and use OmegaT for OpenOffice.org using PO files and
> other PO-based projects as well...
> Trust me, I've done lots of writing converters for the translate
> toolkit and to get the thing totally right is a fair bit of work, so I
> think its best to use existing work

Well I suppose this idea is even better :-)

Ciao, Sabine

       

       
               
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

davidf (Bugzilla)
In reply to this post by Axel Hecht
Axel Hecht wrote:

> Dwayne Bailey wrote:
>
>> On Thu, 2005-11-10 at 12:33 +0100, Sabine Cretella wrote:
>>
>>>>> I forgot: it is already used for OpenOffice.org localisation.
>>>>>  
>>>>
>>>> Just to clarify.  Its used IIRC for .sxw and .od* files.  It isn't
>>>> used
>>>> for l10n of the interface, unless its learnt PO since last I looked.
>>>>  
>>>>
>>> How does the file to be translated look like before it is converted to
>>> .po files?
>>
>>
>> OpenOffice uses an internal format called GSI or SDF.  Its essentially a
>> tab delimeted flat file of all translations.  The translate toolkit
>> unbundles that to PO format.  Which is what most teams doing GUI
>> translation are using.
>>
>>> There are also OpenSource XLIFF editors and there are already XLIFF
>>> conversion tools for .po files around.
>>
>>
>> Yes there are and they're gaining functionality.  PO will I hope someday
>> be replaced by XLIFF.
>
>
> In any environment that is slightly similar to mozilla, that is, cvs
> based with separate repositories for en-US and other locales, this is
> not going to fly. Nobody is going to merge the changes in the en-US
> files into xliff. I'm not sure if xliff does anything about parameters
> in localized strings, but from what I can tell from the three pages I
> glanced at it's seriously over-engineered.

Those are slightly contradictory criticisms - XLIFF does loads to handle
parameters, and that's partly why it seems over-engineered, because it
handles just about any scenario for localization across lots of
different kinds of projects.

>>> Sorry, I am not a programmer, but just a localiser working with very
>>> different sourcecode files (c++, java etc.) it could well be that
>>> there's no conversion to .po necessary.
>>
>>
>> For OOo?  Nope the base format is maddening!
>> Although I'd class Mozilla's disparate files as worse for localisation.
>> Im Mozilla we still have configuration in translations files, we have 2
>> different file formats doing weird things like requiring escaped Unicode
>> (great for Latin languages a nightmare for anyone else), we have a
>> random selection of how to represent accesskeys, we have a handful of
>> other files that need localisation.  In fact I'm always amazed at how
>> much l10n actually gets done.  
>
>
> Well, there are two conceptually different requirements in our
> localization story. The first one is to easily insert replaced content
> into XML. If there are better ways than DTDs, I'd be glad to hear
> about them.
> The other one is parameters in localizable strings. DTDs don't offer
> that (at least not printf friendly), properties do.
> The encoding story with property files is a sad one, yes. Any decent
> editor for property files should work around that, though. Not that I
> know of any, of course.

Is parameters the only reason for using properties? In that case
something could be hacked up to support using parameters from DTDs
perhaps...

>> We must be a dedicated bunch.  Either that or masochists :)
>
>
> It's an overall compromise. We have lots of l10n teams out there, but
> there are still more coders on the UI part or core, that are happily
> using two rather easy techniques, where each of them fits best.
>
> And yes, I don't know anybody in the FOSS enviroment that is not
> really dedicated.

Still good to keep thinking if there are better or simpler ways to do
things ... the issues become more apparent when you're doing
localizations across projects and not just for mozilla or another project

Cheers
David

PS It's a bit of a shame that Reply to All to a message to mozilla-l10n
ends up carrying a Newsgroup: netscape.public.mozilla.l10n header as
well as CC: [hidden email] ... would there be any way to avoid
this automatically?
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: OmegaT [was L10n tool]

Gudmund Areskoug-2
In reply to this post by Rod Whiteley
David Fraser wrote:

> Rod Whiteley wrote:
>
>> Giacomo Magnini wrote:
>>
>>> ...[OmegaT] can already handle (X)HTML files...
>>
>>
>>
>>> ...it doesn't like getting already translated files...
>>
>>
>>
>>> The real problem would be the management of accesskeys and their
>>> bindings to the entities...
>>
>>
>>
>>> Adding po support, xpi writing and cvs support would be the next steps.
>>> I think you can stretch OmegaT in doing those things, but I don't
>>> think it would be OmegaT anymore...
>>
>>
>>
>> I agree.
>>
>>> All you need to start working on the source is getting it...
>>
>>
>>
>> I got the source, and I can sort of see how to make a filter for a new
>> file type, but I'm not sure that I want to become an OmegaT developer.
>> The requirements are specific to Mozilla.  So I think perhaps the
>> solution should be in the Mozilla environment.
>>
>> I'm thinking of a new tool that reads Mozilla source code and writes
>> it in formats that OmegaT can use.  For example, when it reads .dtd it
>> writes .properties.  When it reads an existing translation it writes a
>> translation memory.
>>
>> Then, after the translation is done it reads OmegaT's target files and
>> writes them back as Mozilla source.  When it writes them back, it also
>> provides a way for you to assign access keys.
>>
>> This is only for localization.  It does not access CVS, make XPIs, etc.
>>
>> If I wrote a tool like that, would anyone use it?
>>
> This seems a bit crazy to me. Why not rather use the translate toolkit
> to convert things to .PO format and then get OmegaT to understand PO
> format. That way you should be able to take advantage of different
> translations, and use OmegaT for OpenOffice.org using PO files and other
> PO-based projects as well...
> Trust me, I've done lots of writing converters for the translate toolkit
> and to get the thing totally right is a fair bit of work, so I think its
> best to use existing work
>
> David

I've got some GPL:ed Java code that parses and filters po and pot file
content, both directions and in batch if need be. I had it made to
convert the translatables into a certain format for processing in my
favourite CAT.

It might be a bit dated, and I'm no programmer so I can't judge how
useful it is, but someone in the know taking a look at it can't hurt much.

For lack of a better place to put it, I put it up in the files area of
the Linuxfortranslators list
(http://groups.yahoo.com/group/linuxfortranslators/) along with a (also
dated, by now) ultra short po tool primer, but I'd be happy to see it
someplace where it can be of better use.

BR,
Gudmund
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Robert Kaiser
In reply to this post by Axel Hecht
Axel Hecht schrieb:
> Dwayne Bailey wrote:
>> Yes there are and they're gaining functionality.  PO will I hope someday
>> be replaced by XLIFF.
>
> In any environment that is slightly similar to mozilla, that is, cvs
> based with separate repositories for en-US and other locales, this is
> not going to fly.

 From my experience with a PHP project, even .po in CVS is a headache,
as with every change that causes different line numbers for the same
stuff in source files, you get really big diffs in the .po files which
store the line numbers as well.
 From what I see, the mozilla formats are fitting better with source
code management tools than e.g. the gettext .po format is.

Robert Kaiser
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Yury Tarasievich
On 14 November 2005 13:51, Robert Kaiser wrote:
...
>  From my experience with a PHP project, even .po in CVS is a headache,
> as with every change that causes different line numbers for the same
> stuff in source files, you get really big diffs in the .po files which
> store the line numbers as well.
>  From what I see, the mozilla formats are fitting better with source
> code management tools than e.g. the gettext .po format is.

The end of story is that better fit with source code management doesn't make
translations, while better fit for doing actual translating work does.

-cheers

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: L10n tool]

Axel Hecht
In reply to this post by Robert Kaiser
Yury Tarasievich wrote:

> On 14 November 2005 13:51, Robert Kaiser wrote:
> ...
>>  From my experience with a PHP project, even .po in CVS is a headache,
>> as with every change that causes different line numbers for the same
>> stuff in source files, you get really big diffs in the .po files which
>> store the line numbers as well.
>>  From what I see, the mozilla formats are fitting better with source
>> code management tools than e.g. the gettext .po format is.
>
> The end of story is that better fit with source code management doesn't make
> translations, while better fit for doing actual translating work does.

Well, you're picking the small part of the code that you're involved in.
We have quite a few teams, yes, but you're working on a small portion of
the code, and a small part of the process.

There are by far more contributors to the non-l10n repository. And there
are things like release-management and builds, which do require a
thorough code-management. Which is greatly aided by the cvs-based
webtools like bonsai or lxr, and the cvs/tinderbox-based build process.

It's not like just using some l10n-semi-friendly format would just,
plop, get you mac-builds on the same day as en-US.

Or make it reasonable for mozilla to manage the tree lockdown in the
light of the 1.5 release.

The Mozilla Firefox project is *very* different to other FOSL projects
in that it includes a *huge* portion of so-called "productization". This
step does include QA, lockdowns, builds etc. Stuff that is much better
done with cvs than with other systems. Compromising on the system will
have it's cost, and the first one could likely be simultaneous releases.

Axel
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
12