MozillaTranslator 5.13 RFEs
Ricardo Palomares Martinez
I plan to release a new version of MozillaTranslator in the next
couple of weeks, because I've managed to solve some minor bugs and
annoyances, and I was thinking of some additional features, but before
working on them, I'd like to know if you MT users would find them
interesting enough to devote time to work on it.
The fixes MT 5.13 will include because they're already done are these:
- in MT 5.12 I managed to get DTDs with PE references (like some
brand.dtd files and netError.dtd) to be correctly parsed, but I
forgot to persist in Glossary.zip the external entities found in
them (not as bad as it may sounds, since all info to be saved is in
the original files, so a simple Update Product / CVS Import
Directory will be enough). :-/ I've solved that.
- in MT 5.12 you could get a localized install.properties to be
shipped inside language and content packs, but if you didn't place
a copy of install.properties in the same directory than
Glossary.zip, the XPI build failed, because MT was unable to
extract out the install.properties copy bundled in mt512.jar
itself. This works now.
- finally, the focus is not lost when you edit a string directly in
the table view (Chrome View, Update Product, etc.) and end the
editing pressing [Enter]. The same applies when setting/unsetting
Keep original and Fuzzy flags.
Besides that, the single current enhancement already in place comes
from a RFE from Iacopo Benesperi. You will find in the button toolbar
above the table view these new buttons:
- Fuzzy
- Unfuzzy
- Keep Or.
- Unkeep Or.
- Clear trns.
You may now select multiple rows (consecutive or not) and use the
previous buttons to mark them as fuzzy, not fuzzy, keep original, not
keep original, or to clear the translation text, all with a single click.
Giacomo Magnini gave me two RFEs, and I'm thinking about doing other
enhancements; all of them are listed behind. Please comment if you
find them useful or not, and add yours (not that I'm saying that I
will do them for sure, I just want to know what other *simple* things
you would add to MT).
RFEs
----
- MT should be able to generate automatically the right filename for
XPIs following mozilla.org conventions (Giacomo).
- MT should allow any number of files/folders to be shipped inside the
XPIs, so the resulting file already include default bookmarks,
searchplugins, etc. (Giacomo).
- MT should provide a nice way of telling it how to reorder exported
CVS directories (Ricardo), so you could have a single product for,
let's say, the whole shared components (dom, netwerk, security,
toolkit) with the en-US CVS structure:
- mozilla/dom/locales/en-US/...
- mozilla/netwerk/locales/en-US/...
- mozilla/security/manager/locales/en-US/...
- mozilla/toolkit/locales/en-US/...
and still be able to export the translation in the right way:
- l10n/ab-CD/dom/...
- l10n/ab-CD/netwerk/...
- l10n/ab-CD/security/manager/...
- l10n/ab-CD/toolkit/...
(Shared components are indeed a bad example because of
security/manager being an exception to the directories layout,
but you get the idea).
- MT should have additional QA features similar to the ones provided
by Locale Inspector by Jeferson Hultman, or by KBabel for that
matter
(http://docs.kde.org/development/en/kdesdk/kbabel/kbabel-features.html#kbabel-validation).
I specially value the string parameter (%S, %1$S, etc.) checks.
New and existing QA features should be able to be run in a single
option, maybe adding a non-persisted string column to the table
view in which the problems found could be added in a aggregate
description (Ricardo).
Giacomo's first RFE is something I don't think to worth the effort,
because MT saves the last name used, so you don't need to be writing
the whole filename every time, and I'm not even sure if there is
enough information right now for it to build the name automatically.
The second one is more interesting, but I honestly don't know if
Custom files section could do the trick. Has anyone tested it?
Anyway, please let me know what you think of all this and add whatever
(small) :-) RFEs you feel it may worth the effort.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Robert Kaiser
> Anyway, please let me know what you think of all this and add whatever
> (small) :-) RFEs you feel it may worth the effort.
Not sure small it is, but it would be cool if we would export files in a
way so that the diff to the original is as minimal as possible, i.e.
only the strings themselves are changed, everything else stays as it was
(eventually the localizers could be added to the "Contributors" block of
a maybe existing license header. Most important should be the order of
exported strings, but ideally comments and line spaces would stay intact
as well.
Another RFE would be to parse and display localization notes for the
strings so that a localizers will actually be able to read those and not
ignore them just because he never sees them.
Robert Kaiser
Ricardo Palomares Martinez
I said "small". :-) These two things are more difficult to implement,
because for both DTD and Properties files the problems are the same:
comments are by default ignored, and line numbers are considered an
"implementation detail" and not available at parsing time.
Anyway, both RFEs are in the list for my final year project which I
dream of as the future replacement of MozillaTranslator, and of which
I've just outlined the schedule (but I refrain from making it public,
as these things always get delayed). :-)
If I advance in my FYP at good pace and I manage to implement these
features in it, I'll try to port them to MozillaTranslator.
Regarding the other RFEs I posted, "no comment" means that having them
available is just OK, or that they aren't appealing to you?
Robert Kaiser
> Regarding the other RFEs I posted, "no comment" means that having them
> available is just OK, or that they aren't appealing to you?
They're nice, and I'd not need all of them, but as long as we have users
of them, it's nice to have them :)
Robert Kaiser
Robert Kaiser
> I said "small". :-)
OK, OK, here' s small RFE:
sort files in chrome view by their name ;-)
And I spotted two bugs in current MT:
1) It looks to me like migrating a product doesn't work any more.
2) I have a MT 5.0x glossary where I updated a too deep directory
structure, so it probably has some "damaged" data regarding that one.
When I now update in MT 5.12, it pops up an error message, probably
because of this damaged entry, and instead of failing gracefully and
correcting the glossary error, it doesn't update the whole SeaMonkey
trunk en-US.jar I used and I'm missing a few strings.
Here's the output the error spits to the console:
-------------------------------
Oct 6, 2006 3:24:18 PM org.mozillatranslator.io.StructureAccess loadOriginal
SEVERE: Error reading jar file
java.lang.ClassCastException: org.mozillatranslator.datamodel.PlainFile
at
org.mozillatranslator.io.StructureAccess.loadOriginal(StructureAccess.java:156)
at
org.mozillatranslator.io.StructureAccess.load(StructureAccess.java:67)
at org.mozillatranslator.datamodel.Platform.load(Platform.java:135)
at
org.mozillatranslator.runner.UpdateProductRunner.run(UpdateProductRunner.java:96)
-------------------------------
Could it be that the plain file the (old) glossary has instead of the
directory is something the update can't handle?
Robert Kaiser
Iacopo Benesperi
> Besides that, the single current enhancement already in place comes
> from a RFE from Iacopo Benesperi. You will find in the button toolbar
> above the table view these new buttons:
>
> - Fuzzy
> - Unfuzzy
> - Keep Or.
> - Unkeep Or.
> - Clear trns.
>
> You may now select multiple rows (consecutive or not) and use the
> previous buttons to mark them as fuzzy, not fuzzy, keep original, not
> keep original, or to clear the translation text, all with a single click.
I'm very happy you reached to do it! So I'm waiting for the new version
now :-D
About the other things: I don't need everything, but as Kairo said: the
more we have, the better it is!
bye,
Iacopo
Michele Dal Corso
and makes translating Firefox a less geek work!
I have a single RFE: could you remove the tedious tooltip that appears
when the mouse cursor hovers the columns of the string tables? The text
of the tooltip say "Click on header to sort by column, Shift+Click -
Reverse order.".
This tooltip is very annoying, because it covers working texts while you
are doing translating work.
Thank you
Michele Dal Corso
Tsahi Asher
i agree. it bothers me too.
--
Tsahi Asher
Hebrew L10n Team
http://www.mozilla.org.il
Tsahi Asher
(currently 24) and work on them. some of them could already be fixed,
but nobody bothered to update them. perhaps you should ask to be default
assignee for MozillaTranslator component.
Ricardo Palomares Martinez
> OK, OK, here' s small RFE:
> sort files in chrome view by their name ;-)
I'll look into it. I had thought myself of doing it, but I'm not
really sure if that's trivial or not.
> And I spotted two bugs in current MT:
> 1) It looks to me like migrating a product doesn't work any more.
>
Yep, I have to look into it too.
> 2) I have a MT 5.0x glossary where I updated a too deep directory
> structure, so it probably has some "damaged" data regarding that one.
> When I now update in MT 5.12, it pops up an error message, probably
> because of this damaged entry, and instead of failing gracefully and
> correcting the glossary error, it doesn't update the whole SeaMonkey
> trunk en-US.jar I used and I'm missing a few strings.
I don't really understand the "too deep directory structure" comment.
In MT 5.0x, you can only have two directory levels. :-?
> Here's the output the error spits to the console:
> -------------------------------
> Oct 6, 2006 3:24:18 PM org.mozillatranslator.io.StructureAccess
> loadOriginal
> SEVERE: Error reading jar file
> java.lang.ClassCastException: org.mozillatranslator.datamodel.PlainFile
> at
> org.mozillatranslator.io.StructureAccess.loadOriginal(StructureAccess.java:156)
> -------------------------------
> Could it be that the plain file the (old) glossary has instead of the
> directory is something the update can't handle?
Yep, it seems that MT 5.0x glossary had an empty file instead of the
directory, and now it tries to cast the PlainFile to Component, which
of course fails.
Are you using a JAR file? If so, you may want to try to recreate it
without creating directory entries ("-D" flag for zip command-line
version). This could prevent MT from creating the empty file entry. If
that doesn't work, then the only solution I see (besides fixing the
program, of course) would be temporarily creating the JAR file with
the "right" directory levels, updating the MT 5.0x glossary with that
file, and then upgrading to MT 5.1x.
Robert Kaiser
>> 2) I have a MT 5.0x glossary where I updated a too deep directory
>> structure, so it probably has some "damaged" data regarding that one.
>> When I now update in MT 5.12, it pops up an error message, probably
>> because of this damaged entry, and instead of failing gracefully and
>> correcting the glossary error, it doesn't update the whole SeaMonkey
>> trunk en-US.jar I used and I'm missing a few strings.
>
> I don't really understand the "too deep directory structure" comment.
> In MT 5.0x, you can only have two directory levels. :-?
The jar file has three levels, and when MT 5.0x imported/updated this
file, it created a plain file on the second level instead of the
directory and stuffed some file content from below that dir into it.
This is where the plain file below comes from...
>> Here's the output the error spits to the console:
>> -------------------------------
>> Oct 6, 2006 3:24:18 PM org.mozillatranslator.io.StructureAccess
>> loadOriginal
>> SEVERE: Error reading jar file
>> java.lang.ClassCastException: org.mozillatranslator.datamodel.PlainFile
>> at
>> org.mozillatranslator.io.StructureAccess.loadOriginal(StructureAccess.java:156)
>> -------------------------------
>> Could it be that the plain file the (old) glossary has instead of the
>> directory is something the update can't handle?
>
> Yep, it seems that MT 5.0x glossary had an empty file instead of the
> directory, and now it tries to cast the PlainFile to Component, which
> of course fails.
Would be nice if it could gracefully fail in that situation and
correctly update the glossary to the new structure it reads from the jar
file.
> Are you using a JAR file? If so, you may want to try to recreate it
> without creating directory entries ("-D" flag for zip command-line
> version). This could prevent MT from creating the empty file entry. If
> that doesn't work, then the only solution I see (besides fixing the
> program, of course) would be temporarily creating the JAR file with
> the "right" directory levels, updating the MT 5.0x glossary with that
> file, and then upgrading to MT 5.1x.
The file entry is not empty, AFAIK, it has been filled with more or less
garbage by MT 5.0x - I'd like to get it out of the glossary somehow and
have MT update to the correct structure now that it supports it.
I can probably try to do a jar file without that additional dir level
and update it in MT 5.0x, but I'm not sure if that version will remove
the plain file from the glossary...
Robert Kaiser
Giacomo Magnini
> available is just OK, or that they aren't appealing to you?
A few others (just ideas, not actual RFE):
- a Search button inside the Edit dialog (useful for finding a string
inside a help file, for example); or, even better, after a search, the
edit dialog will open with the searched string highlighted and under the
cursor
- move the search items out of the edit menu (overloaded) on their own menu
- the export xpi dialog should remember the settings for the exported
modules, not just the name, author, etc.
Ciao, Giacomo.
K. an Drouizig
I'd just like to send you some feedback about Mozilla Translator 5.12.
I am the lead of the br-FR localization of Firefox/Thunderbird, though
our team is not yet registered as "official" partner of the Mozilla
Foundation.
Our team has been using MozillaTranslator for many months now and it
has been a real pleasure to see annoying bugs fixed by someone recently
(I mean the netError.dtd file trash with MT 5.04 for instance).
I would like to report you two bugs that remain with 5.12 though (with
Firefox 2.0 RC3):
* The locale\browser\preferences\tabs.dtd file is not correctly
generated. the line %brandDTD; is generated without the final ; (which
is compulsory).
* I still have wrong key bindings which are not discovered (about 5). I
found that some of the labels have 2 .accesskey entries (for example,
foo.accesskey and foo.accesskey2. The second one is not taken into
account by MT 5.12. There might be other reason why wrong accesskeys are
not found, may be you know about it ?
Anyway thank you very much for your dedication, it does help a lot !
Best Regards,
Phil
BTW, The Breton localisation of Mozilla Firefox 2:0 RC3 is 100%
complete and can be downloaded from http://www.drouizig.org
================================
Kevredigezh « An Drouizig »
Teknologiezhoù nevez e brezhoneg
http://www.drouizig.org
drou...@drouizig.org <mailto:drou...@drouizig.org>
Ricardo Palomares Martinez
> Ricardo Palomares Martinez schrieb:
>> In MT 5.0x, you can only have two directory levels. :-?
>
> The jar file has three levels, and when MT 5.0x imported/updated this
> file, it created a plain file on the second level instead of the
> directory and stuffed some file content from below that dir into it.
> This is where the plain file below comes from...
Sorry, I've been a full week without phone line (and, therefore,
without ADSL). I'm still puzzled, I can't fully understand how you get
this error. Is there any way for me to reproduce your scenario? Maybe
you would be willing to send me a copy of your 5.0x Glossary.zip or
the JAR you're working with? You can use the e-amil address from which
I post this message, just removing ".PUBLI".
The fact is that I'd like to fix that before releasing MT 5.13, which
is otherwise ready and wrapped, so any help you could give me to
reproduce the problem would be welcomed.
Thanks in advance.
Ricardo Palomares Martinez
> A few others (just ideas, not actual RFE):
> - a Search button inside the Edit dialog (useful for finding a string
> inside a help file, for example); or, even better, after a search, the
> edit dialog will open with the searched string highlighted and under the
> cursor
That sounds nice, I'll take a look into it, but I think it would
better wait until 5.14, do everybody agree with this?
> - move the search items out of the edit menu (overloaded) on their own menu
I've done a bit of reorganization into the Edit menu for 5.13, so I
think we better wait until you see the new menu layout.
> - the export xpi dialog should remember the settings for the exported
> modules, not just the name, author, etc.
For 5.13 I've done something that suits me, although maybe it doesn't
suit you: all checkboxes are set by default now, so you usually just
need to uncheck "Region" if you are recreating the langpack, which
seems to be the most usual thing. Again, wait till 5.13 and let me know.
Ricardo Palomares Martinez
> I am the lead of the br-FR localization of Firefox/Thunderbird, though
> our team is not yet registered as "official" partner of the Mozilla
> Foundation.
Just out of curiosity, br-FR? Brazillian spoken in France?
>
> * The locale\browser\preferences\tabs.dtd file is not correctly
> generated. the line %brandDTD; is generated without the final ; (which
> is compulsory).
I guess MT 5.13 is no longer ready and wrapped. :-) I have to go out
right now, but I'll look deeper tonight, it should be a fairly simple
issue (that file has PUBLIC PE, versus netError.dtd or brand.dtd,
which have a SYSTEM PE).
>
> * I still have wrong key bindings which are not discovered (about 5). I
> found that some of the labels have 2 .accesskey entries (for example,
> foo.accesskey and foo.accesskey2. The second one is not taken into
> account by MT 5.12. There might be other reason why wrong accesskeys are
> not found, may be you know about it ?
If a single label has two accesskeys, there is no solution right now,
as MozillaTranslator datamodel expects a 1:0..1 relation between label
and accesskey. Anyway, I remember having seen something like you
describe, and I regarded it as a bug to be fixed by Mozilla developers
more than a real need to hold two accesskeys (but I could be wrong).
You could try to add ".accesskey2" as an accesskey suffix in File ->
Setup -> Key connections, but MT will still link in a 1:0..1
cardinality, and I can't guarantee which acesskey will prevail (the
first one in the accesskey suffix list, probably).
>
> Anyway thank you very much for your dedication, it does help a lot !
>
Thanks a lot for your support.
Ricardo
K. an Drouizig
> Just out of curiosity, br-FR? Brazillian spoken in France?
ah!! no ISO-639-1 standard says : brETON spoken in FRance
And for many projects we've been fighting for a while to keep this "br" under control...
& it is true to say that it is often used (stolen...)
as a shortcut to pt-BR - portuguese spoken in Brazil = brazilian !
> I guess MT 5.13 is no longer ready and wrapped. :-) I have to go out
> right now, but I'll look deeper tonight, it should be a fairly simple
> issue (that file has PUBLIC PE, versus netError.dtd or brand.dtd,
> which have a SYSTEM PE).
Great. Actually I have noticed that this problem also shows in
locale\xx-XX\global\netError.dtd
locale\xx-XX\global\brand.dtd
> Thanks a lot for your support.
Kindly,
Phil.
Mark Tyndall
> K. an Drouizig escribió:
>> I am the lead of the br-FR localization of Firefox/Thunderbird, though
>> our team is not yet registered as "official" partner of the Mozilla
>> Foundation.
>
> Just out of curiosity, br-FR? Brazillian spoken in France?
No, Breton (Brezhoneg).
regards,
Mark..
--
British English localisations of:
SeaMonkey <http://www.tyndall.org.uk/moz_en-gb.html>
Firefox <http://www.tyndall.org.uk/fb_en-gb.html>
Thunderbird <http://www.tyndall.org.uk/tb_en-gb.html>
Ricardo Palomares Martinez
>> Just out of curiosity, br-FR? Brazillian spoken in France?
>
> ah!! no ISO-639-1 standard says : brETON spoken in FRance
Oops, sorry!
>> I guess MT 5.13 is no longer ready and wrapped. :-) I have to go out
>> right now, but I'll look deeper tonight, it should be a fairly simple
>> issue (that file has PUBLIC PE, versus netError.dtd or brand.dtd,
>> which have a SYSTEM PE).
>
> Great. Actually I have noticed that this problem also shows in
>
> locale\xx-XX\global\netError.dtd
> locale\xx-XX\global\brand.dtd
I guess you refer to /browser/locales/en-US/chrome/overrides/netError.dtd:
http://lxr.mozilla.org/mozilla1.8/find?string=netError.dtd
For brand.dtd, I can't find any suitable file with a PE:
http://lxr.mozilla.org/mozilla1.8/find?string=brand.dtd
This is solved now (I'm ashamed for the other thing I've just
discovered while adding the ";"). I just have to look into Robert's
old Glossary problem.
Thank you for the report.