Some news on Mozilla Translator
Ricardo Palomares Martinez
The patch Axel did to generate UTF-8 encoded .properties files has a
minor glitch when the string to be saved as a value includes newlines.
Java honors the escape codes and save the string in the file with real
newlines, which breaks the standard.
I've fixed it replacing both "\n" and "\t" characters for "\\n" and
"\\t", the two I remember having seen in strings to be translated.
Also, I've added some properties to the Product definition to save the
CVS paths used, so you don't have to browse the filesystem every time
you want to import or export files.
The problem is that I've changed my ISP and I don't actually have a
permanent website to put the new files, so I'd like to know how many
of you are using Mozilla Translator in order to setup a temporary
place at NAVE website and upload it.
While we are on the subject, I'm right now refactoring Mozilla
Translator code so it can deal with an arbitrary number of directory
levels. I've just finished modifying the code that saves the
Glossary.zip; it compiles, but of course I can't test it right now.
:-) As a plus, the program size could decrease little bit, since there
is a fair amount of duplicated and redundant code.
Mozilla Translator users, let me know so I can decide what should I do
with the latest stable JAR.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Iacopo Benesperi
> Mozilla Translator users, let me know so I can decide what should I do
> with the latest stable JAR.
here in Italy we use it in 3-4 people to translate almost everything.
bye,
Iacopo
Axel Hecht
can a file an RFE here?
One thing that's getting more and more important as we're committing
localizations to CVS is licensing.
Localizations are a modification of the original source, and as such,
should include at least one of the original licenses. For committing
them into the Mozilla CVS repository, they need to be triple licensed.
There are a few misconceptions about this in the wild, which are
enhanced by MT just dropping the original license. But in the end, the
use of the tool doesn't change the license under which one got the
source, and it's be nice if MT could make that more obvious.
So, RFE: please make the serialization code include the original license
header. Minor RFE, localizers may want to add themselves to the list of
contributors, that's a tad more tricky code wise, though.
Thanks
Axel
Sorin Batariuc
Romanian translation of SeaMonkey.
Any chances to see in the new version "find and replace" function? I
really need this, or maybe some similar tool for replacing words/strings
in jar files.
Thank you.
Ricardo Palomares Martinez wrote:
>
Iacopo Benesperi
> Any chances to see in the new version "find and replace" function? I
> really need this, or maybe some similar tool for replacing words/strings
> in jar files.
There's already something similar in MT. I can't access it now so I
can't read the exact string; but if you look in Search menu I'll find
something like "Autotranslate [...]" that translate automatically
strings which match exactly (case sensitive) to another already translated.
For example: if you have 40 "Cancel" strings, you can translate one and
then use Autotranslate. It isn't so much, but better than nothing, though ;)
Iacopo
João Miguel Neves
POFileFill from gettext-lint tools. Works fine for me.
Best regards,
João Miguel Neves
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
Ricardo Palomares Martinez
> So, RFE: please make the serialization code include the original license
> header. Minor RFE, localizers may want to add themselves to the list of
> contributors, that's a tad more tricky code wise, though.
Actually, the MT code in Sourceforge.net already has some work in
progress to allow licenses to be attached to individual files, but I
think it wasn't finished and I haven't entered into details yet.
Adding a fixed string to every licensed file ("Translated by John
Doe") shouldn't be an impossible task, and I'll try to do it, but I
don't see an easy way (without adding additional UI) to allow
different files to have different localizers. MT is not a multiuser
tool, but it's perfectly possible that several localizers use MT and
one of them acts as a collector, merging partial translation into one,
consolidated Glossary.zip. For them, the easy solution would be just a
partial one.
Anyway, I'm doing changes in MT as a way to get accostumed to Java and
the IDE; ultimately, I hope to come out with a brand-new l10n tool
that won't have these limitations.
Tsahi Asher
> Hi,
>
> Mozilla Translator users, let me know so I can decide what should I do
> with the latest stable JAR.
>
> Ricardo.
>
we (hebrew l10n) use MT for SeaMonkey and firefox/thunderbird, a total
of two people.
--
Tsahi Asher
Hebrew L10n Team
http://www.mozilla.org.il
Michele Dal Corso
> Translator code so it can deal with an arbitrary number of directory
> levels. I've just finished modifying the code that saves the
> Glossary.zip; it compiles, but of course I can't test it right now.
> :-) As a plus, the program size could decrease little bit, since there
> is a fair amount of duplicated and redundant code.
Nice to hear this from you! I'm using MT to translate Firefox in
Italian, and I like it.
Please, could you implement a feature that deletes non-used strings from
glossary when you update a CVS directory translation?
This causes me to re-create the glossary each time that a string
become obsolete (because obsolete strings breaks compare-locale script
check).
Alternatively it will be good a way to manually delete an obsolete
string from the glossary.
Thank you for your interest on MT!
Michele Dal Corso
Robert Kaiser
> Axel Hecht escribió:
>> So, RFE: please make the serialization code include the original license
>> header. Minor RFE, localizers may want to add themselves to the list of
>> contributors, that's a tad more tricky code wise, though.
>
> Actually, the MT code in Sourceforge.net already has some work in
> progress to allow licenses to be attached to individual files, but I
> think it wasn't finished and I haven't entered into details yet.
The best thing MT could do would be to somehow remember the layout of
the original files and write the translated files out in the same
structure, including, newlines and comments (which include license headers).
Robert Kaiser
Robert Kaiser
> The problem is that I've changed my ISP and I don't actually have a
> permanent website to put the new files, so I'd like to know how many
> of you are using Mozilla Translator in order to setup a temporary
> place at NAVE website and upload it.
We can probably host your packages on ftp.mozilla.org, I think we have a
directory for such stuff (L10n tools) there.
A different solution could be to set up a mozdev project where you can
host the modified source and downloads...
In any case, I'd be very happy to have your fixed packages, as I'm using
the current buggy version along with some custom fixup scripts for my
German SeaMonkey branch and trunk nightly XPIs, which are broken right
now, probably due to this bug.
Robert Kaiser
Sorin Batariuc
> There's already something similar in MT. I can't access it now so I
> can't read the exact string; but if you look in Search menu I'll find
> something like "Autotranslate [...]" that translate automatically
> strings which match exactly (case sensitive) to another already translated.
> For example: if you have 40 "Cancel" strings, you can translate one and
> then use Autotranslate. It isn't so much, but better than nothing,
> though ;)
about what and how this command works, because it is like blind mode,
the program is doing something (probably) but I can't see anything.
Under <Search> or <Advanced Search> menus, there is no <Autotranslate>,
my MT version is 5.05pl4.
Ricardo Palomares Martinez
> Ricardo Palomares Martinez schrieb:
>> The problem is that I've changed my ISP and I don't actually have a
>> permanent website to put the new files, so I'd like to know how many
>> of you are using Mozilla Translator in order to setup a temporary
>> place at NAVE website and upload it.
>
> We can probably host your packages on ftp.mozilla.org, I think we have a
> directory for such stuff (L10n tools) there.
Well, I've uploaded the ZIP (including the JAR and the OO2 document)
and the sources ZIP at NAVE website:
http://nave.escomposlinux.org/otros/mt505pl4.zip
http://nave.escomposlinux.org/otros/mt505pl4_src.zip
I've created a file "unofficial_changelog.txt" inside the JAR, in
org/mozillatranslator.
Remember, this version just have minor fixes, and still is not able to
cope with more than two directory levels. I don't know how much it's
going to take me that, so if anyone thinks that uploading the files to
ftp://ftp.mozilla.org/pub/mozilla.org/l10n-kits would be good, go ahead.
I think I'm going to have to build a RFE list. :-)
Ricardo Palomares Martinez
> Ricardo Palomares Martinez schrieb:
>> progress to allow licenses to be attached to individual files, but I
>> think it wasn't finished and I haven't entered into details yet.
>
> The best thing MT could do would be to somehow remember the layout of
> the original files and write the translated files out in the same
> structure, including, newlines and comments (which include license
> headers).
I think that's not so easy. I have some ideas for the l10n program I
intend to write, but I don't see an easy way to do it in MT. Besides,
I need to have something "brand new" for my final year project. :-)
Ricardo Palomares Martinez
> Nice to hear this from you! I'm using MT to translate Firefox in
> Italian, and I like it.
>
> Please, could you implement a feature that deletes non-used strings from
> glossary when you update a CVS directory translation?
> This causes me to re-create the glossary each time that a string
> become obsolete (because obsolete strings breaks compare-locale script
> check).
> Alternatively it will be good a way to manually delete an obsolete
> string from the glossary.
There is a poor man solution at this moment. It's abit annoying, but
it works. Do this before you are going to run Export -> CVS Translation:
- Rename the MT product to product-old (i.e.: browser -> browser-old).
It just involves changing the name. While you are at it, select and
copy the Import Original CVS Path.
- Create a new product named "browser". Paste the Import Original CVS
Path.
- It would be nice if you go back to "browser-old" and copy and paste
Import/Export Translation CVS Path, too.
- Go to Import -> CVS Directory and choose the new "browser" product.
Dismiss the updated strings window.
- Go to Advanced -> Migrate Product and migrate from "browser-old" to
"browser" wit your locale.
The result is that only current strings are copied, and "Keep"
checkboxes are preserved.
I'm going to have to deal with Update Product and CVS Import Directory
for the refactoring, so maybe I will be able to enhance the process.
> Thank you for your interest on MT!
You're welcome. MT keeps being my main l10n tool, and I really love
using it. :-)
Ricardo Palomares Martinez
> I have found <Autotranslate> under <Edit> menu, but I don't have a clue
> about what and how this command works, because it is like blind mode,
> the program is doing something (probably) but I can't see anything.
> Under <Search> or <Advanced Search> menus, there is no <Autotranslate>,
> my MT version is 5.05pl4.
I haven't looked the code for AutoTranslate yet, but another option
that works well and not in a blind way is Edit -> Search translation
inconsistency. Once you get the list, you can sort it by Text:
Original to see how the same en-US string has been translated in
different ways.
If you have such a case and change one translation, all strings with
that translation get affected. For instance:
# en-US ab-CD
--------------------------------------
1 Browse the web Examinar la web
2 Browse the web Examinar la web
3 Browse the web Navegar por la web
4 Browse the web Examinar la web
5 Browse the web Surfear la web
If you edit the first translated string and set it to "Navegar por la
web", strings 2 and 4 will automatically get translated, too, while
string 5 will keep as "Surfear la web".
HTH
Ricardo Palomares Martinez
> (...)
> While we are on the subject, I'm right now refactoring Mozilla
> Translator code so it can deal with an arbitrary number of directory
> levels. I've just finished modifying the code that saves the
> Glossary.zip; it compiles, but of course I can't test it right now.
> :-) As a plus, the program size could decrease little bit, since there
> is a fair amount of duplicated and redundant code.
>
A question to MT die hard users: assuming the program works right
otherwise, anyone would find a problem in "MT_default" branches
disappearing?
MT_default branches are created when a file is only at one-level
depth. Mozilla Translator "makes up" a fake subcomponent so every file
is in the same level depth. As my intention is completely remove
subcomponents and turn components into a dir representation,
components and files being children of components, what happens now
(*) is that you may find both a file and a component hanging on the
same parent. It shouldn't matter at all, but I wanted to peek you, in
case that makes a difference for someone.
(*) When I say "now", I mean "NOW": I have just imported the whole
bunch of "toolkit" directories (dom, netwerk, security and toolkit) as
a single product. :-) Of course, this is not of much use, because
en-US appears as a component, and I would have to make sure to replace
the name at exporting time, but it's funny to see a MT product with
seven levels of depth. Surpringsily, BTW, the Chrome View works OK
with no changes, so you can indeed browse and edit the different files
and strings. Even charset.mk and install.it files appear and can be
edited in the same generic way than HTML files, for instance.
Robert Kaiser
> A question to MT die hard users: assuming the program works right
> otherwise, anyone would find a problem in "MT_default" branches
> disappearing?
I'd like that a lot, it's been superficial anyways...
> (*) When I say "now", I mean "NOW": I have just imported the whole
> bunch of "toolkit" directories (dom, netwerk, security and toolkit) as
> a single product. :-) Of course, this is not of much use, because
> en-US appears as a component, and I would have to make sure to replace
> the name at exporting time, but it's funny to see a MT product with
> seven levels of depth. Surpringsily, BTW, the Chrome View works OK
> with no changes, so you can indeed browse and edit the different files
> and strings. Even charset.mk and install.it files appear and can be
> edited in the same generic way than HTML files, for instance.
WOW! Cool! Awesome! ;-)
Robert Kaiser
Giacomo Magnini
> and the sources ZIP at NAVE website:
>
> http://nave.escomposlinux.org/otros/mt505pl4.zip
> http://nave.escomposlinux.org/otros/mt505pl4_src.zip
After creating the first xpi, saving and closing, I'm now unable to
create again another xpi: I always get an error writing the file: the
jar is null... Any idea? Switching back to previous MT versions with the
same Glossary produces the same output.
Using Java6b2 (win).
Cheers, Giacomo.
Ricardo Palomares Martinez
> After creating the first xpi, saving and closing, I'm now unable to
> create again another xpi: I always get an error writing the file: the
> jar is null... Any idea?
I'd need the exception dump to take a look at it. I've just tried to
export the XPI again and it has worked OK (twice).
> Switching back to previous MT versions with the
> same Glossary produces the same output.
You probably have a problem with the glossary itself. The only changes
in the glossary format that mt505pl4 introduces are the CVS paths, and
such a change makes safe to move the glossary back and forth to
different MT versions (you'll only lose the CVS paths).
You know that you can unzip Glossary.zip and browse glossary.txt for
corrupted chars or so, don't you?
> Using Java6b2 (win).
Wow! You like to live on the edge. :-)
Giacomo Magnini
> export the XPI again and it has worked OK (twice).
9-lug-2006 9.01.27 org.mozillatranslator.io.StructureAccess save
INFO: making settings
9-lug-2006 9.01.27 org.mozillatranslator.io.StructureAccess save
INFO: Kernel.setttings org.mozillatranslator.kernel.Settings@44f787
9-lug-2006 9.01.27 org.mozillatranslator.io.StructureAccess save
INFO: Entering gui mode
9-lug-2006 9.01.27 org.mozillatranslator.io.StructureAccess save
INFO: Beginning: Load glossary
9-lug-2006 9.01.30 org.mozillatranslator.io.StructureAccess save
INFO: Finished: Load glossary
9-lug-2006 9.01.32 org.mozillatranslator.io.StructureAccess save
INFO: Showing action dialog null
9-lug-2006 9.02.49 org.mozillatranslator.io.StructureAccess save
INFO: Beginning: Write XPI
9-lug-2006 9.02.49 org.mozillatranslator.io.StructureAccess save
INFO: Exporting platform neutral
9-lug-2006 9.02.49 org.mozillatranslator.io.StructureAccess save
INFO: Starting writeing textfile intl.css
9-lug-2006 9.02.50 org.mozillatranslator.io.StructureAccess save
GRAVE: Error writeing jar file
java.lang.NullPointerException
at java.io.FilterOutputStream.write(Unknown Source)
at org.mozillatranslator.io.common.FileUtils.saveFile(FileUtils.java:51)
at
org.mozillatranslator.io.common.FileUtils.saveFileWithLicense(FileUtils.java:81)
at
org.mozillatranslator.io.StructureAccess.writeFile(StructureAccess.java:371)
at org.mozillatranslator.io.StructureAccess.save(StructureAccess.java:325)
at org.mozillatranslator.datamodel.Platform.save(Platform.java:147)
at
org.mozillatranslator.runner.WriteXPIRunner.taskImplementation(WriteXPIRunner.java:101)
at org.mozillatranslator.kernel.MozTask.run(MozTask.java:62)
at java.lang.Thread.run(Unknown Source)
9-lug-2006 9.02.50 org.mozillatranslator.runner.WriteXPIRunner
taskImplementation
GRAVE: Error writing xpi file
java.io.IOException: Error writing jar file
null
at org.mozillatranslator.io.StructureAccess.save(StructureAccess.java:340)
at org.mozillatranslator.datamodel.Platform.save(Platform.java:147)
at
org.mozillatranslator.runner.WriteXPIRunner.taskImplementation(WriteXPIRunner.java:101)
at org.mozillatranslator.kernel.MozTask.run(MozTask.java:62)
at java.lang.Thread.run(Unknown Source)
Does this help? It comes from your own build.
> You probably have a problem with the glossary itself. The only changes
> in the glossary format that mt505pl4 introduces are the CVS paths, and
> such a change makes safe to move the glossary back and forth to
> different MT versions (you'll only lose the CVS paths).
>
> You know that you can unzip Glossary.zip and browse glossary.txt for
> corrupted chars or so, don't you?
Will try to compare the actual glossary with a previous version, but it
probably predates the big changes that came with the new CZ, the SSL
changes and the rename of Label to Tag. Anyway, will report back any
strange bit I find.
> Wow! You like to live on the edge. :-)
Not so much on the edge: from version 5 I've found the JDK/JRE to be
much speedier and much more robust than previous versions.
Ciao, Giacomo.
Giacomo Magnini
> Does this help? It comes from your own build.
I've just updated again the product (all of them: SM, DOMI, CZ, etc.)
and now the xpi export seems to work again... Weird.
Ciao, Giacomo.
Michele Dal Corso
> There is a poor man solution at this moment. It's abit annoying, but
> it works. Do this before you are going to run Export -> CVS Translation:
> The result is that only current strings are copied, and "Keep"
> checkboxes are preserved.
I used this procedure just now and it works perfectly! Thank you a lot:
you saved me a lot of time (no more hundred o clicks to restore keep
original boxes!) :-)
> You're welcome. MT keeps being my main l10n tool, and I really love
> using it. :-)
Me too! And now MT is more efficient! Good luck on improving MT!
Michele
Ricardo Palomares Martinez
Yes, because it looked like either the ZIP or the file hadn't been
successfully created. I can't tell you for sure, although I'm sure
that I hadn't touched any line involved in a XPI generation (except
for the changes you did to use the scripts from Robert, but I don't
think it can be related).
Anyway, let me know if it happens again, please.
Tsahi Asher
> Ricardo Palomares Martinez escribió:
> A question to MT die hard users: assuming the program works right
> otherwise, anyone would find a problem in "MT_default" branches
> disappearing?
>
some components have a lot of files in them. if the files will hang
directly under the component, the tree might get very long, even when you
don't need to access the files in the component root. perhaps it will be
enough to change the name to something else, like "[root]" or something.
Ricardo Palomares Martinez
> ציטוט Ricardo Palomares Martinez:
>> A question to MT die hard users: assuming the program works right
>> otherwise, anyone would find a problem in "MT_default" branches
>> disappearing?
>>
> some components have a lot of files in them. if the files will hang
> directly under the component, the tree might get very long, even when you
> don't need to access the files in the component root. perhaps it will be
> enough to change the name to something else, like "[root]" or something.
Humm, the problem is not the name, but faking a directory where it
doesn't exist. With the old assumption, it was easy to decide if a
fake subcomponent had to be made: the file has to directly hang of a
component to create a "MT_default" subcomponent.
Now, everything but a file will be a "file holder", and if I have to
create a fake "file holder", it will always be a component. I still
will be able to decide based on the parent name, but I'd have to check
if that's always possible.
Robert Kaiser
> Humm, the problem is not the name, but faking a directory where it
> doesn't exist. With the old assumption, it was easy to decide if a
> fake subcomponent had to be made: the file has to directly hang of a
> component to create a "MT_default" subcomponent.
>
> Now, everything but a file will be a "file holder", and if I have to
> create a fake "file holder", it will always be a component. I still
> will be able to decide based on the parent name, but I'd have to check
> if that's always possible.
I think that would be too complicated... Just make sure to sort any "fie
holders"/directories before normal files, though, so it's easy to
navigate...
Robert Kaiser
Giacomo Magnini
A good start would be bugzilla itself:
product: Mozilla Localizations
component: MozillaTranslator
Quite a few... ;)
Ciao, Giacomo.
Giacomo Magnini
I can actually reproduce it all of the times: I just narrowed the
"Update product" to just "SeaMonkey", to actually be able to write a
working xpi.
Ciao, Giacomo.
Ricardo Palomares Martinez
Can you elaborate on this, please? I'm not sure if you mean that
trying to write an XPI for a product other than SeaMonkey causes the
crash.
BTW, in the logs I see that the file being exported at crash time
seems to be intl.css:
> 9-lug-2006 9.02.49 org.mozillatranslator.io.StructureAccess save
> INFO: Beginning: Write XPI
> 9-lug-2006 9.02.49 org.mozillatranslator.io.StructureAccess save
> INFO: Exporting platform neutral
> 9-lug-2006 9.02.49 org.mozillatranslator.io.StructureAccess save
> INFO: Starting writeing textfile intl.css
> 9-lug-2006 9.02.50 org.mozillatranslator.io.StructureAccess save
> GRAVE: Error writeing jar file
Take a look at it, or if you want, send me your Glossary.zip (you can
use this address removing ".PUBLI"), or you can use my bugzilla e-mail
address; you can find it in this bug, for instance:
https://bugzilla.mozilla.org/show_bug.cgi?id=343321