First of all note this is AFAIK and that i'm not a mozilla developer nor specialist nor user (only when i'm on windows that is not much).
You probably noted that yesterday Mozilla tried to eclipse our 3.5 release with Firefox 1.5 release, i thought, ok, i'll download it so my father can use it on its Windows machine, so there i go to http://www.mozilla.com/firefox/all.html to get the catalan version of Firefox 1.5 for Windows and wooops, it's not there :-/ So my father is forced to use the old 1.0.7 version.
Obviously i'm not requesting to have a fully 100% translated catalan version of Firefox when we don't have one in KDE (http://i18n.kde.org/stats/gui/stable/ca/index.php) but at least a 1.5 release reusing the strings from 1.0.7 would be enough as i'm almost sure most strings are the same, but Mozilla foundation has historically been a bit bad on the i18n side making translation teams provide the i18n'ed binaries instead of doing the build along the English binary and that cause that kind of problems.
I hope they can solve this issue with i18n as it's one of the strong points Free Software has.
4 comments:
AFAIK, Mozilla i18n teams do a huge work to release language package very fast.
For example, about french translation, we were used to wait several weeks after the english release.
Magically, this time,at the very first day of 1.5 release, 8 languages were available, including french.
Perhaps Catalan i18n could try to catch with the same process ? I'm not sure it's a "Mozilla" pb....
What do you think ?
For me it is. Translations teams should only translate and mozilla should do the release with all the translations in that have a "good enough" level like we do in KDE. As said i'm sure not much messages changed, and that reusing 1.0.7 messages to 1.5 would have put Catalan in a "good enough" level.
Obviously i'm not blaming Mozilla i18n Teams here.
The Mozilla applications are very badly run for being open source apps. After all those years one would think they finally separated all the problematic parts, e.g. offering Gecko and XUL as runtime libraries separate from the different Mozilla applications etc. Instead they keep building those basically statically leading to every Mozilla apps having its own version of Gecko/XUL which not only increased memory used by redundant data, but also makes it necessary to update every single app when a grave bug in Gecko is found. That, considering these all, Mozilla apps regularly break binary compatibility and do nothing to separate out text strings for easy swapping of translations is just the icing on the cake really.
I totally agree with the previous comment. Basically, firefox commiters are former Netscape employees and Windows geeks. They hardly know something about open-source software release management.
Post a Comment