270266 - Mozilla Translator considered harmful

Status: RESOLVED FIXED

(Mozilla Localizations Graveyard :: MozillaTranslator, enhancement)

Description

[Anne (:annevk)]

The Mozilla Translator should be either be forbidden or updated. It makes files
a mess after they are updated and removes important things like license
agreements (in comments).

Comment 1

[RickieES aka Ricardo Palomares]

License agreements issue has been solved.

Regarding the order of entities, it's a side effect of using a real XML parser (and the standard Java class to deal with Properties files), and shouldn't really be an issue. It's clearly not an issue for Mozilla applications, since translations made with MozillaTranslator are perfectly functional, and shouldn't be an issue for humans, as:

1) one of the purposes of a CAT tool like MozillaTranslator is to relieve translators the burden of dealing with the underlying structure of files. You see keys, original strings and translated strings, not lines in a file.

2) If you really need to access the translated file, at least for DTD files the keys are saved in alphabetical order by key.

Keeping open for a few days, in case anyone wants to comment.

Comment 2

[u81239]

For translation projects, it definitely is an issue. Namely, it makes it very hard to compare a translation with the original files. One might argue that that’s not a problem as long as one uses MT, but then again not every translator uses MT, and when e.g. comparing patches in Bugzilla MT also can’t be used. Also, it messes up the location of e.g. translation notes (in comments), which are vital to the translations.

So, please don’t disregard it as an unimportant problem. Preserving the order doesn’t seem like a strange or impossible requirement, and it is necessary for MT to be useful for localisation.

A lot of effort had to be spent negating the effects of MozillaTranslator-ed files in the nl-NL CVS.

Please do not close this bug, as the original reported issue has not been solved.


~Grauw

Comment 3

[u81239]

p.s. technical details of a certain implementation in no way make the problem go away.

Comment 4

[RickieES aka Ricardo Palomares]

(In reply to comment #2)
> For translation projects, it definitely is an issue. Namely, it makes it very
> hard to compare a translation with the original files. One might argue that
> that’s not a problem as long as one uses MT,

Of course, that's the point of using the tool, not having to worry about dealing directly with the files.


> but then again not every translator uses MT,

Well, I really think that a l10n team must choose a CAT as whole. Some members using MT, others using Translate-toolkit and the rest using just UTF-8 editors sounds not like the right decision to me.


> and when e.g. comparing patches in Bugzilla MT also can’t be used.

That's not my experience at all. I use MT to translate CVS-based products like Firefox and Thunderbird, and MT exports files sticking to the same order every time, so if you need to compare an updated translated file (the ab-CD version of the updated file somestrings.dtd, for instance), you won't get a big diff due to entity oneString.label being exported sometimes at top of file and sometimes at the middle, for instance. You will only get the updated strings, and AFAICT, strings are dumped alphabetically sorted on entity/property name.

Of course, if you previously translated by hand and followed en-US layout, and then you export with MT you will get a different order and thus a big diff. If you then translate again by hand, you'll get again a different order and again a big diff.


> Also, it messes up the location of e.g. translation notes (in
> comments), which are vital to the translations.


I understand that being able to read translation notes while using MT is important sometimes (vital in a few cases, handy for majority of notes, and superfluous the rest). I'll try to do it if I have enough time.

What I don't see is the need to preserve the localization notes on translated files. Anyone advanced enough to deal with translated files shouldn't have any problem to look up for en-US original file.


> 
> So, please don’t disregard it as an unimportant problem. Preserving the order
> doesn’t seem like a strange or impossible requirement, and it is necessary for
> MT to be useful for localisation.


Well, it is somewhat strange to me (although I've thought of some ideas to implement it in my own L10n tool; doing it for MT is a luxury for me right now), and it is not as easy as you may think; to be effective, the DTD files must be read with a real XML parser, and this implies that you don't have the line number nor can guarantee an specific order.

And, of course, es-ES and other languages show that MT is useful for localization indeed.


> A lot of effort had to be spent negating the effects of MozillaTranslator-ed
> files in the nl-NL CVS.
> 
> Please do not close this bug, as the original reported issue has not been
> solved.


I'm not closing this bug, but I'm targeting "Future" at this moment because I don't think it really affects localization unless some l10n team decides to switch back and forth from MT-based to editor based localization, and I don't have enough time for this now, sorry.

I hope to get MT source code again in Sourceforge.net repository some time (not my fault, really), and then anybody will be able to work in a coordinated way, allowing you or anybody else to provide patches for this bug.

Comment 5

[RickieES aka Ricardo Palomares]

Just for the record, MT sources are up to date again in sourceforge.net's CVS.

Comment 6

[Axel Hecht [:Pike]]

Just running across random bugs, and I guess this one is safe to be marked FIXED. There are quite a few teams with MT files, and they're not landing reordered files and comment borkages, AFAICT.