Forthcoming new MozillaTranslator version
Ricardo Palomares Martinez
With the wonderful help of Tsahi Asher, I (we, actually) have got a
bunch of fixes and new features ready for a new version of
MozillaTranslator.
I'm going to start using it as production tool right now, and intend
to update the docs and any bug I catch through this incoming week, in
order to release it by next weekend. Main new features of this version
are:
* Localization notes parsing
* Many UI enhancements
* Better QA checks
If anybody wants to test it, let me know and I will send you the JAR
zipped. Or, you may get the updated sources from Sourceforge.net and
build it yourself.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Ricardo Palomares Martinez
> Hi,
>
> With the wonderful help of Tsahi Asher, I (we, actually) have got a
> bunch of fixes and new features ready for a new version of
> MozillaTranslator.
>
> I'm going to start using it as production tool right now, and intend
> to update the docs and any bug I catch through this incoming week, in
> order to release it by next weekend. Main new features of this version
> are:
>
> * Localization notes parsing
> * Many UI enhancements
> * Better QA checks
>
> If anybody wants to test it, let me know and I will send you the JAR
> zipped. Or, you may get the updated sources from Sourceforge.net and
> build it yourself.
>
If any of you have taken a loot to CVS commits, you already know that
I've modified the code after sending the message. It seems that
incremental builds sometimes play tricky and hide some errors. In this
case, the change from SaveGlossaryRunner from a Thread to a MozTask
subclass made that saving on quit didn't work anymore.
I've solved it in a non very elegant way (status messages don't show
up), but changes needed to get everything working right would need a
lot of work, since MT has been always a bit broken in GUI thread
management.
Fortunately, nobody has asked for a test version so far... :-)
Mad Maks
>
> If anybody wants to test it, let me know and I will send you the JAR
> zipped. Or, you may get the updated sources from Sourceforge.net and
> build it yourself.
>
> Ricardo.
>
please send me a testversion.
greetings
MM
Alexander Ihrig
could you test the new version with Enigmails translation? MT 5.13 has a
problem when exporting the translation in a jar file - some exported
DTD/properties files have 0 kb. MT 5.05 works without problems. I'm not
sure why this problem exists, maybe because of HTML-Code in Enigmails
Strings?
Regards
Alex Ihrig
Thunderbird-Mail.de
Alexander Ihrig
The file enigmail.dtd and update080.html have no more strings IN MT 5.13
- all strings get lost.
Alexander Ihrig schrieb:
Giacomo Magnini
> If anybody wants to test it, let me know and I will send you the JAR
> zipped. Or, you may get the updated sources from Sourceforge.net and
> build it yourself.
Count me in...
Ciao, Giacomo.
Marcelo Poli
>
> If anybody wants to test it, let me know and I will send you the JAR
> zipped. Or, you may get the updated sources from Sourceforge.net and
> build it yourself.
>
Another spanish speaking wanting to test the new MT.
Send it to enzomatrix ---AT--- gmail.com please.
Ricardo Palomares Martinez
> I'm going to start using it as production tool right now, and intend
> to update the docs and any bug I catch through this incoming week, in
> order to release it by next weekend.
> If anybody wants to test it, let me know and I will send you the JAR
> zipped. Or, you may get the updated sources from Sourceforge.net and
> build it yourself.
I should have thought how much embarassing this was going to be before
posting the above... :-)
To enable localization notes parsing, I had to rewrite the
java.util.properties load() method (*). While it worked fine with the
properties files I tested (browser.properties, custom.properties and
metaData.properties, mainly), some nasty errors have been unveiled
when doing real field tests. I have solved some of them, but I need to
take a detailed look to a couple more (new lines handling for both
Unix and Windows line termination, and ending line spaces), so I'm
afraid I can't send it to any of you before fixing those bugs.
I'll try to fix it by tomorrow night (approx. 00:00 UTC). Besides,
I'll try to take a look to Enigmail issue mentioned by Alexander Ihrig.
Sorry, I've should learned by now to refrain from doing this kind of
announcements...
Ricardo.
PS.: (*) BTW, in the load() rewrite, I've just assumed that keys (not
values) are always in a single line. The Java Properties spec enables
a key to be split in several lines, like this:
a.multiple.\
line.key = a single line value for a multiple line key
...but I don't think we have nothing like that in Mozilla Properties
files, and assuming it doesn't happen makes code more readable. Anyone
thinks that this simplification could be a problem?
Ricardo Palomares Martinez
> To enable localization notes parsing, I had to rewrite the
Well, I've spent more time than I thought in this but I think it is
solved. While I was debugging it I've unvelied a funny thing in a
properties file contents, and their handling by both MT and other
tools/editors... Please, take a look at:
http://lxr.mozilla.org/mozilla1.8/source/mail/locales/en-US/chrome/messenger/mime.properties#221
1031=<B><FONT
COLOR=\042#808080\042> Internal</FONT></B>
I think there is an error in that escape sequence "\042". I've
compared it with pt-BR (I chose it because it is easy for me to read
portuguese) and es-ES translations (AFAIK, pt-BR is not using
MozillaTranslator, whereas es-ES is):
http://lxr.mozilla.org/l10n-mozilla1.8/source/pt-BR/mail/chrome/messenger/mime.properties#222
1031=<B><FONT
COLOR=\\042#808080\\042> Interno</FONT></B>
http://lxr.mozilla.org/l10n-mozilla1.8/source/es-ES/mail/chrome/messenger/mime.properties#35
1031 = <B><FONT
COLOR=042#808080042> Interno</FONT></B>
pt-BR tool/editor is "escaping" the backslash, thus altering the
original character sequence (the previous L10n note says that
everything should left as is except the word "internal"). OTOH, Java
parsing in MozillaTranslator 5.1x, which is the standard
java.util.Properties parsing on a UTF-8 file instead of ISO-8859-1,
"disregarded" the backslash as it couldn't parse the escaped character
sequence.
This may be just an error in the original en-US file, but I wonder how
Mozilla parses back these two different handlings (pt-BR and es-ES),
and maybe even en-US, too.
For those of you that wanted to test MT 5.20, please be patient. I'll
try to do a round of loading/updating/reviewing/saving with every
product I manage with MT (firefox, thunderbird, seamonkey, calendar
and toolkit) before letting you suffer from my own lack of testing.
:-) Besides, I have to check Enigmail translation issues.
I really wanted to release MT 5.20 by weekend, but I doubt I will be
able to update all the user guide in time. Sorry for the delay.
Ricardo.
Robert Kaiser
> Well, I've spent more time than I thought in this but I think it is
> solved. While I was debugging it I've unvelied a funny thing in a
> properties file contents, and their handling by both MT and other
> tools/editors... Please, take a look at:
>
> http://lxr.mozilla.org/mozilla1.8/source/mail/locales/en-US/chrome/messenger/mime.properties#221
>
> 1031=<B><FONT
> COLOR=\042#808080\042> Internal</FONT></B>
>
> I think there is an error in that escape sequence "\042".
I think this sequence is correct, as .properties files may not allow a
quotation mark (") in a string, but the string needs to end up as the
correct HTML tag |<FONT COLOR="#808080">| (yes, even though this is HTML
3.2 and deprecated in HTML4 - but that's a different bug).
> pt-BR tool/editor is "escaping" the backslash, thus altering the
> original character sequence (the previous L10n note says that
> everything should left as is except the word "internal").
And I think it might come out the wrong way after being parsed by Mozilla.
es-ES is wrong from the beginning, it can't end up the right way after
any parsing.
> This may be just an error in the original en-US file, but I wonder how
> Mozilla parses back these two different handlings (pt-BR and es-ES),
> and maybe even en-US, too.
I'd believe that only the en-US one ends up as a correct HTML tag...
Robert Kaiser
Axel Hecht
> Ricardo Palomares Martinez schrieb:
>> Well, I've spent more time than I thought in this but I think it is
>> solved. While I was debugging it I've unvelied a funny thing in a
>> properties file contents, and their handling by both MT and other
>> tools/editors... Please, take a look at:
>>
>> http://lxr.mozilla.org/mozilla1.8/source/mail/locales/en-US/chrome/messenger/mime.properties#221
>>
>>
>> 1031=<B><FONT
>> COLOR=\042#808080\042> Internal</FONT></B>
>>
>>
>> I think there is an error in that escape sequence "\042".
>
> I think this sequence is correct, as .properties files may not allow a
> quotation mark (") in a string, but the string needs to end up as the
> correct HTML tag |<FONT COLOR="#808080">| (yes, even though this is HTML
> 3.2 and deprecated in HTML4 - but that's a different bug).
Reading
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Properties.html#load(java.io.InputStream)
the escape is wrong, I think it's trying to be an octal escape.
Looking at
http://lxr.mozilla.org/mozilla1.8/source/xpcom/ds/nsPersistentProperties.cpp#184
we, at this particular instance, implement that accordingly to the spec.
Taking the string literally, spain is broken right, portuguese is broken
wrong.
Right is only '"', or if you actually need a \ for your happiness, \",
but, as the java doc mentions, that'd be just noise.
Want to check where that string is used and how? Sounds like a bug.
Axel
Ricardo Palomares Martinez
>
> If anybody wants to test it, let me know and I will send you the JAR
> zipped. Or, you may get the updated sources from Sourceforge.net and
> build it yourself.
Well, finally I've been using MT 5.20 as the production version for
some days (with Firefox, Toolkit and SeaMonkey) and I think I can
trust it enough for those braves who want to test it. :-) I've
uploaded the JAR (just the JAR, as I don't have the user guide updated
yet); you can find the download link in the Download section at:
http://www.proyectonave.es/otros/
As I've mentioned there, there are still some issues, so please be
careful out there.
Ricardo Palomares Martinez
> could you test the new version with Enigmails translation? MT 5.13 has a
> problem when exporting the translation in a jar file - some exported
> DTD/properties files have 0 kb. MT 5.05 works without problems. I'm not
> sure why this problem exists, maybe because of HTML-Code in Enigmails
> Strings?
I've tried updating from 0.9.0 to 0.9.2 and then exporting everything
in "CVS mode" (ie., not creating a JAR or langpack XPI but simply a
directory layout with files in it), and everything went well, so I
guess MT 5.20 final will work OK.
Alexander Ihrig
Regards
Alex Ihrig
Ricardo Palomares Martinez
> MT 5.20 seems to be okay for the Enigmail translation.
>
Glad to know that somebody still remembers that I talked about MT
5.20. :-) Tsahi has handed me the last set of fixes/enhancements on
GUI chrome view, and I'm giving the final touches. I'm not sure if I
will be able to finish the reviewed MT guide, but I surely will upload
a "beta" which will be indeed the final JAR this weekend.