245831 - Provide information how to localize Firefox

Status: RESOLVED FIXED

(Firefox :: General, defect, P1)

Description

[Martin Creutziger [:MMx]]

So far there is no information for localizers of Firefox how to deal with the
new update mechanism, Firefox Help, and all the other changed components.

If localized versions of Firefox are wanted close to the release of Fx0.9, this
information must be provided now.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

confirming.
and please, give us a few days between stabilizing locales and releasing 0.9.

Comment 2

[Kadir Topal [:atopal]]

I've asked for this for several times now and didn't get any answer. Even though
several big changes applied to Firefox -including the breaking of the
languagepack xpi's- there was no posting about that in the l10n-NG. We'll have
to communicate, if l10n is important for you. The way it's handled now is
somewhat frustrating.

Comment 3

[Steffen Wilberg]

What kind of information do you need? A changelist, maybe more detailed than the
Firefox roadmap?

The help system consists of the help content in
mozilla/browser/components/help/locale/en-US/
(the xhtml files) and the help viewer in in
mozilla/toolkit/components/help/locale/en-US/

Firefox 0.9, 1.0 beta and 1.0 will be build from the AVIARY_1_0_20040515_BRANCH,
so be careful to get a branch build. The trunk is not current in all aspects.

Comment 4

[Steffen Wilberg]

Forgot to mention that help is packaged into help.jar.

http://update.mozilla.org will be launched along with 0.9. It will list
extensions and themes. It is contacted by the new extension/theme manager when
looking for updates. The "get new" extensions/themes links point to that as well.
I don't know wheter it will host language packs and whether that site itself
will be localised. Probably yes. I just asked in
http://forums.mozillazine.org/viewtopic.php?t=78912 .

Information on the new extension manager can be found in the extensions forum in
mozillazine, http://forums.mozillazine.org/viewforum.php?f=19 , especially in
this thread: http://forums.mozillazine.org/viewtopic.php?t=73423

Comment 5

[Steffen Wilberg]

Mike just checked in my patch for bug 181541, which adds a dialog to "select the
default language and character encoding for websites" to
Tools->Options->General. The language and region names are in
languageNames.properties and regionNames.properties. They should be translated.
But these files should be identical to the files used by SeaMonkey.

Comment 6

[Steffen Wilberg]

Wolf said:
"At launch, update.mozilla.org will not be including language packs. They can be
added later." I filed bug 245946 about that.

"I don't know of any plans for localized versions of the site, at this time.
That's not to say it won't happen though, with some help."
I filed bug 245948 about localizing Mozilla Update.

Comment 7

[Mark Tyndall]

(In reply to comment #3)
> What kind of information do you need? 

I'd like to know how to bundle the language pack - ie, how to build the XPI.
For the Suite, there are several guides available (eg,
<http://www.mozilla.org/projects/l10n/mlp_packaging.html>, which goes into
considerable (and needed) detail).

With the abandoning of install.js as the method of installation,
<http://texturizer.net/firefox/localize.html> (an equivalent guide for Firefox)
is now out of date; AFAICT, none of the l10n community currently know how to
package a new extension.  I suspect that many localisers, me included, build
an XPI 'by numbers'.  If we don't have something to go on, there will be a
considerable delay between the release of 0.9 in US English, and the release of 
language packs and localised versions, as we will have to reverse engineer the
en-US pack and distribute the knowledge gained (with language barriers slowing
this down).

> Firefox 0.9, 1.0 beta and 1.0 will be build from the AVIARY_1_0_20040515_BRANCH,
> so be careful to get a branch build. The trunk is not current in all aspects.

Erm, I've never needed to download stuff from CVS before to produce a language pack.
For the Suite, I simply have to download the (truly cross-platform)
langenus.xpi (as I did this morning for 1.7rc3) to be able to produce the
corresponding langengb.xpi.  It would be ideal if I could follow the same
(or a similar) procedure for Firefox packs (and also for TB packs - see
bug 243167).

Comment 8

[Benoit]

FWIW, I've been able to open FirefoxSetup-0.9rc.exe with 7zip. 

It still contains a langenus.xpi, but same as Thunderbird in bug 243167, only
en-win.jar and en-US.jar are inside the archive. 

There is an install.js, but no install.rdf that would help us to make an
external language pack. 

A localized installer could probably be made using the command-line version of
7zip as in http://lxr.mozilla.org/mozilla/source/browser/installer/windows/7zip.bat

I think it would be something like that:
* extract all the files from FirefoxSetup-0.9.exe with 7zip
* replace install.ini, config.ini and langenus.xpi in the uncompressed folder
* put http://lxr.mozilla.org/mozilla/source/browser/installer/windows/app.tag
and an upx-compressed version of 7zSD.sfx somewhere in the path
* recompress with something like
 > 7z a -t7z ..\7z\app.7z *.* -m0=LZMA:d25m:fb128 -mx9
 > copy /b 7zSD.sfx+app.tag+app.7z FirefoxSetup-<lang>-0.9.exe

No idea on how it could be done on other platforms.

Comment 9

[Kadir Topal [:atopal]]

I for one am curious about how autoupdate will work. E.g. what if someone has
installed a localised version 0.9 and uses autoupdate for firefox. Will
autoupdate update his firefox version when english firefox 1.0 becomes available? 

Comment 10

[Jérôme Schell]

Well, I made some little progress in building a french .xpi langpack for
Thunderbird 0.6+ (should be the same for Firefox 0.9).
The organization is as follow :
langpack.xpi:
   install.rdf
   chrome/fr-FR-mail.jar
   chrome/fr-win.jar
   chrome/fr-unix.jar
   chrome/fr-mac.jar
   chrome/frenchlocale.jar
   defaults/messenger/FR/mailViews.dat
   components/myspell/README_fr_FR.txt
   components/myspell/fr-FR.aff
   components/myspell/fr-FR.dic

The install.rdf is written as explained in
http://www.bengoodger.com/software/mb/extensions/packaging/extensions.html.
The frenchlocale.jar file contains a xul file that acts as preferences window
for the extension. There is just a checkbox in it that permits to enable or
disable the use of the lang.

Problems I still have :
- I don't know how to select between platform dependant files (xx-win.jar,
xx-mac.jar, xx-unix.jar) with the new install.rdf system.
- I have to delete the XUL.mfasl everytime I close Thunderbird otherwise I have
no displayed account anymore :(

If someone is interrested I have put my xpi there :
http://jschell.nerim.net/thunderbird/nightlies/thunderbird-fr-FR-langpack.xpi

Comment 11

[Axel Hecht]

(In reply to comment #10)
<...>
> Problems I still have :
> - I don't know how to select between platform dependant files (xx-win.jar,
> xx-mac.jar, xx-unix.jar) with the new install.rdf system.
<...>

I'm afraid this is a general shortcoming of Ben's update manager. You cannot 
have alternatives. Note that this doesn't just involve platforms, but languages
as well. I see no architecture to support the current push of l10n on mozdev
extensions, for example. AFAICT.
I created a blog entry at http://www.axel-hecht.de/blog/archives/000112.html for 
more public detail/discussion.

Comment 12

[Zibi Braniecki [:zbraniecki][:gandalf]]

Axel: could You create separate bug for this and CC people from this bug? It can
be a blocker for localizers, and it would be great to have it before 1.0

Comment 13

[Michele Dal Corso]

(In reply to comment #10)

> If someone is interrested I have put my xpi there :
> http://jschell.nerim.net/thunderbird/nightlies/thunderbird-fr-FR-langpack.xpi

I realised a similar xpi based on your instructions and xul for firefox 0.9. It
does not need to delete xul.mfl file.
The xpi is here:
http://www.mozillaitalia.org/files/firefox/0.9/firefox0.9-lang-it-IT.xpi

Comment 14

[matsuba]

My japanese language pack for Firefox 0.9 RC is here.
http://www33.ocn.ne.jp/~snip/mozilla/firefox/jlp/firefox0.9rc-langjajp-tm0.1.xpi

It contains my language-pack-swithcer extension(lpswitcher.jar).

http://www33.ocn.ne.jp/~snip/mozilla/firefox/index.html

It provided about Global installation for Language pack.
Sorry. This page is written in Japanese.

Comment 15

[Jérôme Schell]

Would it be possible to have several install.rdf files?
Say install-win.rdf, install-mac.rdf and install-unix.rdf.
So Firefox/Thunderbird would search for the install-PLATFORM.rdf with
PLATFORM="the platform the extension is being installed on" and if it can't find
it, search for the simple install.rdf file. This way we could, for exemple, do
per-platform installation for some platform and have a default for the other
platform in the install.rdf. I think perhaps this shouldn't be to hard to
implement :)

Comment 16

[matsuba]

I should add this comment.
If we want to startup with -P or -ProfileManager by using native language pack,

1. Global Install
2. Register your language pack by using lpswither.
3. Once rename your profile.
   In unix. mv $HOME/.mozilla $HOME/mozilla.bak

4. firefox -ProfileManager -UILocale ja-JP -contentLocale JP

Comment 17

[matsuba]

Attachment: screen shot

Screenshot by "firefox -ProfileManager -UILocale ja-JP -contentLocale JP"

Comment 18

[Alexander L. Slovesnik]

(In reply to comment #16)
> I should add this comment.
> If we want to startup with -P or -ProfileManager by using native language pack,
> 
> 1. Global Install
> 2. Register your language pack by using lpswither.
When I made global installation of language pack ( firefox.exe
-install-global-extension firefox0.9rc-langjajp-tm0.1.xpi ), I can not change
language with lpswither. When I selecting Options from context menu, Firefox
don't show them, it shows error window. I'm using Firefox 0.9rc on Windows.   

Comment 19

[Alexander L. Slovesnik]

Attachment: Screenshot of error

Screenshot of error when selecting Options from context menu.

Comment 20

[matsuba]

(In reply to comment #18)

I'm now working in office. (^^;

Global Install:
1. Download Language pack(firefox0.9rc-langjajp-tm0.1.xpi) in /tmp.
2. firefox -install-global-extension  /tmp/firefox0.9rc-langjajp-tm0.1.xpi 
application
3. firefox -enableExtension "{02d61967-84bb-455b-a14b-76abc5864739}"   

  {02d61967-84bb-455b-a14b-76abc5864739}: 
    This GUID is Japanese Language Pack for firefox.

Please retry this.

Comment 21

[Alexander L. Slovesnik]

(In reply to comment #20)
> (In reply to comment #18)
> 
> I'm now working in office. (^^;
> 
> Global Install:
> 1. Download Language pack(firefox0.9rc-langjajp-tm0.1.xpi) in /tmp.
> 2. firefox -install-global-extension  /tmp/firefox0.9rc-langjajp-tm0.1.xpi 
> application
> 3. firefox -enableExtension "{02d61967-84bb-455b-a14b-76abc5864739}"   
> 
>   {02d61967-84bb-455b-a14b-76abc5864739}: 
>     This GUID is Japanese Language Pack for firefox.
> 
> Please retry this.

OK, that did the trick. Profile Manager is in Japan.
However I cannot switch language with lpswither, using my current profile -
still same error. When I've created new profile - lpswitcher works. Rather queer.
Anyway it's very inconvenient for end users - running firefox with command line
keys like -enableExtension "{02d61967-84bb-455b-a14b-76abc5864739}"

Comment 22

[matsuba]

I think that a cause is this bug.
http://bugzilla.mozilla.org/show_bug.cgi?id=246014
Extension manager does not generate appropriate chrome.rdf entries for locale
entities

Again, it arranged.

###################
#### root user ####
###################
1. cd /usr/local/
2. get firefox-i686-linux-gtk2+xft-2004-06-13-16-0.9.tar.gz from      
   http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-06-13-16-0.9/ .

3. gunzip -dc firefox-i686-linux-gtk2+xft-2004-06-13-16-0.9.tar.gz | tar xvf -
4. mv /root/.mozilla /root/.mozilla.prev
   mv /root/.firefox /root/.firefox.prev
   mv /root/.phoenix /root/.phoenix.prev

5. /usr/local/firefox/firefox -install-global-extension
/tmp/firefox0.9-2004-06-13-16-langjajp-tm0.1.xpi application
  (*) it shows "*** loading the extensions datasource", it returns prompt.

6. Enable Global Extension
  [1] /usr/local/firefox/firefox -enableExtension
"{02d61967-84bb-455b-a14b-76abc5864739}"

  [2] Startup firefox by [1].
  [3] "Tools" -> "Extensions", select Firefox JLP and click "Preferences",
      Click "Japanese(ja-JP/JP), Click [OK].

  [4] Exit firefox.
      (*) not registered in /usr/local/firefox/chrome/chrome.rdf

    <c:selectedLocale RDF:resource="urn:mozilla:locale:en-US:global"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:en-US:communicator"/>



  [5] /usr/local/firefox/firefox -UILocale ja-JP -contentLocale JP
      (*) registered(ie. add selectedLocale) in /usr/local/firefox/chrome/chrome.rdf

    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:inspector"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:communicator"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:pippki"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:autoconfig"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:global"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:help"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:lpswitcher"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:necko"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:global-platform"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:cookie"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:JP:global-region"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:pipnss"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:mozapps"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:browser"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:ja-JP:passwordmgr"/>
    <c:selectedLocale RDF:resource="urn:mozilla:locale:JP:browser-region"/>

####################################
#### none root user(ie. matsuba ####
####################################
1. Clean profile.
   mv .mozilla .mozilla.bak
   mv .phoenix .phoenix.bak
   mv .firefox .firefox.bak

2. /usr/local/firefox/firefox -ProfileManager or /usr/local/firefox/firefox
    (*) It shows in Japanese.

Comment 23

[Bradley Chapman (not reading bugmail, still gone but not forever)]

matsuba's description of his problem sounds exactly like what I have found in
Bug 246014, especially since he is installing locales via XPIs.

Perhaps 246014 should be added to the dependency tree for this bug.

Comment 24

[Steffen Wilberg]

Moving blocking0.9? to blocking1.0?

Comment 25

[matsuba]

(In reply to comment #10)
> Problems I still have :
> - I don't know how to select between platform dependant files (xx-win.jar,
> xx-mac.jar, xx-unix.jar) with the new install.rdf system.

I received the error report from the Mac user, he/she is using my language pack
 for Thunderbird 0.7.

In Thunderbird 0.7:

Only en-mac.jar (in
locale/en-US/communicator-platform/platformCommunicatorOverlay.dtd)
 has historyCmd.key entry. In this case, if language-pack have all platform
dependent files, 
mac users meet parse error message, 

The install.rdf in my japanese-language-pack has three same entries for
ja-win.jar, ja-mac.jar, ja-unix.jar in next order

    <em:file>
      <Description about="urn:mozilla:extension:file:ja-unix.jar">
        <em:locale>locale/ja-JP/communicator-platform/</em:locale>
        <em:locale>locale/ja-JP/global-platform/</em:locale>
        <em:locale>locale/ja-JP/navigator-platform/</em:locale>
      </Description>
    </em:file>

    <em:file>
      <Description about="urn:mozilla:extension:file:ja-mac.jar">
        <em:locale>locale/ja-JP/communicator-platform/</em:locale>
        <em:locale>locale/ja-JP/global-platform/</em:locale>
        <em:locale>locale/ja-JP/navigator-platform/</em:locale>
      </Description>
    </em:file>

    <em:file>
      <Description about="urn:mozilla:extension:file:ja-win.jar">
        <em:locale>locale/ja-JP/communicator-platform/</em:locale>
        <em:locale>locale/ja-JP/global-platform/</em:locale>
        <em:locale>locale/ja-JP/navigator-platform/</em:locale>
      </Description>
    </em:file>

I checked chrome.rdf's entry on my linux box. The result was as follows.

  <RDF:Description RDF:about="urn:mozilla:locale:ja-JP:communicator-platform"
                   c:localeVersion="1.7"
                  
c:baseURL="jar:file:///usr/local/mozilla/thunderbird/0.7/extensions/%7B6d7be712-405c-485a-9630-aa063d6f3a51%7D/chrome/ja-win.jar!/locale/ja-JP/communicator-platform/">
    <c:package RDF:resource="urn:mozilla:package:communicator-platform"/>
  </RDF:Description>

Do I should create language-pack for each platform individually ?

My japanese language pack for Thunderbird 0.7 is here.
http://www33.ocn.ne.jp/~snip/mozilla/thunderbird/jlp/thunderbird0.7-langjajp-tm0.1.xpi

Comment 26

[Steffen Wilberg]

I just posted this to the n.p.m.l10n newsgroup:

> 1. How do you handle the GUID of your fully translated Firefox, which you ship
with the installer? If you leave it as default. The Autoupdate will  inform the
user, when Firefox 9.x en-US is available and download that package. If you
change the GUID, you will be forced to provide an own webservice and even more
importatn: Extensions will always target the GUID of Firefox en-US and won't
work with your GUID. So what shall we do?


Software Update for Firefox works like this:
Software Update checks the pref "update.app.url". That points to
http://update.mozilla.org/update.rdf. That file will provide information on the
current Firefox version available and the url to load in od an update.

That file doesn't even exist yet. But Ben provided a sample update.rdf here:
http://lxr.mozilla.org/aviarybranch/source/toolkit/mozapps/update/src/nsBackgroundUpdateService.js#200

If that file were in place at update.mozilla.org (and served as text/rdf), it
would inform the user that Firefox 1.2 was available. If the user clicks
"Install Now", Firefox would open the Firefox product page at
http://www.mozilla.org/products/firefox/

In other words, it would *not download* an English version of Firefox.

Please do *not* change the GUID. Extensions specify in their install.rdf that
they are compatible with the product {ec8030f7-c20a-464f-9b0e-13a3a9e97384},
which means Firefox. If you change the GUID of Firefox (stored in the pref
"app.id"), they won't install anymore (and if they did, it's a bug that will be
fixed).

Comment 27

[Zibi Braniecki [:zbraniecki][:gandalf]]

Steffen: is there any chance that people working with Firefox will ind time for
localization problems?

The ideal situation with this problem would be that if I'm using Polish Firefox
1.0 and there is 1.1 en-US i should get notice about it. But when Polish Firefox
1.1 is out I should get second notice because THIS is the product i'm using now.

I can't see reaction of polish-speaking users who will find out that Extension
Manager is notyfing them that there is new english version and suggesting to get
it now.

Alsa, as we all know (n.p.m.l10n) there are plenty of problems with localizating
Firefox.

Comment 28

[Oscar Manuel Gómez Senovilla]

From the spanish team:

Since some time, we're having problems to generate a XPI file, and what's more,
just make firefox localization work. We have the localization finished some days
ago, but feel unable to find the way to make it work. We've been using for a
long time Mozilla Translator, and taking a look at the italian package, the
contents are absolutely different from any know previous item. So, I see two
ways here:
1) Provide a "Firefox Translator" tool, to eliminate the pain for localizers to
dedicate too much time to investigate than the translation itself;
2) A way to convert the usual generated packages by MT to "firefox format" (and
versions)

I'm tired of dedicating too much time to this.

Comment 29

[Zibi Braniecki [:zbraniecki][:gandalf]]

> Firefox Translator

I'm developing such application (codenamed gTranslator) which is a
Firefox/Mozilla extension and allows to work on locale resources. (merging two
locales, localizating products, and providing locales for yours products). But
i'm creating it in my free time, and without any help so work is done very
slowly now.

Comment 30

[Kadir Topal [:atopal]]

spanish team: I absolutely feel with you. We are two persons here, trying to
make our 6! builds work (2x win, 2x linux, 1x mac, 1x xpi). It's driving me
crazy how many different files I have to edit and how many things I have to
consider (like bug 244891) or the different locale versions for example I have
to edit by hand, because MT won't allow more than one localeVersion per *jar.
But the most annoying thing is, that nobody from the Firefox-Team even seems to
care (aside from Steffen Wilberg, thank you). Thats frustrating!

Comment 31

[Zibi Braniecki [:zbraniecki][:gandalf]]

Guys. No matter how frustrated we are, we have to remember that localization is
as important as Ben says it is. Not even a little more.

At this point localization is very little important for the project and in
result we have no feedback from authors. The ricochet is that Firefox is _very_
hard to localizating and localizator-unfriendly application, and it takes _a
lot_ of time and human resources to make it working. But i'm afraid we have no
chance for help in near futur. So if any of You have some free time to spend and
wan't to help, please, email me. I think we can ship a nice tool to help ourselfs.

Comment 32

[Steffen Wilberg]

CCing bsmedberg, who said "Since Ben still has a lot of work on his plate, I may
be taking over some of the l10n issues/cleanup from him."

Comment 33

[Martin Creutziger [:MMx]]

I hope that Ben understands how significantly important localization is for the
success of Firefox. Without localization it will never be able to "take back the
web". "The web" is not "the U.S.". Sorry to say that, but it is true.

As soon as my time schedule recovers a little from all the trouble, I might at
least test gTranslator, if that helps.

Comment 34

[Blake Ross]

Localization is very important to us.

Comment 35

[Tristan Nitot]

(In reply to comment #29)
Zbigniew wrote:
> 
> I'm developing such application (codenamed gTranslator) which is a
> Firefox/Mozilla extension and allows to work on locale resources. (merging two
> locales, localizating products, and providing locales for yours products). But
> i'm creating it in my free time, and without any help so work is done very
> slowly now.

Zbigniew, how can we (Mozilla Europe) help? Localisation is an absolute must for
Firefox penetration in Europe.

Comment 36

[Zibi Braniecki [:zbraniecki][:gandalf]]

Tristan: of course i'd like to see someone to help me with free time and
knowledge  of XUL/JS. That's all :) I have a plan, i have part of API, i have
most of XUL interface and lack of time to code JS.

Basing on "blocking 1.0" i'm trying to write a short brief of problems and i
hope this will help Firefox Team find points where Firefox  can be improved.

Comment 37

[chris hofmann]

we are planning to have a firefox localization #irc/conference call very soon
(next week) to discuss any/all the issues around localization.  I hope to have
an agenda constructed soon.  send mail to [e-mail] with ideas for
discussion and specific bug numbers that are hindering translation efforts.  Asa
and I will also be watching this bug.

Comment 38

[Oscar Manuel Gómez Senovilla]

(In reply to comment #37)
> we are planning to have a firefox localization #irc/conference call very soon
> (next week) to discuss any/all the issues around localization.  I hope to have
> an agenda constructed soon.  send mail to [e-mail] with ideas for
> discussion and specific bug numbers that are hindering translation efforts.  Asa
> and I will also be watching this bug.

Is this an approach to (at last) trying to homogeneize the methods and tools for
localizers to not waste their time in reverse-engineering?

Whoever is responsible of this, should do that work, and not even stay unashamed
of Zbigniew doing the work the original team should have done from the very
start. Or maybe they can make him to be paid for his work (not to mentions the
rest of people wasted time).

I think that Mozilla Translator, though not perfect, is pretty good for the
purpose it was created, but the firefox (and somehow thunderbird is not free of
charge) team seems encouraged to outdate it without aparent reason, instead of
promoting and/or improving it. There's no need to reinvent the wheel, just take
the previous and adjust as necessary, since it does properly more than 90% of
the work.

I don't email as you suggested because I consider this of general interest.
There are more mozilla.org products than mozilla, firefox and thunderbird.

Comment 39

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: guide of creating localizations and related problems

i'm attaching a document created on a base of polish localizing team
experiences just to give You idea how our work looks like.
It should also help localization teams create windows installer (some people
asked for such guide)

Comment 40

[Benjamin Smedberg]

After talking with Ben Goodger, I am taking charge of the firefox localization
bugs and decision-making. I have posted a message to
netscape.public.mozilla.l10n with the decisions about the localization of firefox.

news://news.mozilla.org:119/cbfsbd$[e-mail]

Once I get the en-US directory working properly, I will post more detail
directions for localizers.

Comment 41

[Alberto García Fernández]

(In reply to comment #29)
> > Firefox Translator
> 
> I'm developing such application (codenamed gTranslator) which is a
> Firefox/Mozilla extension and allows to work on locale resources.

This is interesting, but be careful. Exists an application called 'gtanslator'.
See http://gtranslator.sourceforge.net/ ('gtranslator is an enhanced gettext po
file editor for the GNOME desktop environment'
<http://gtranslator.sourceforge.net/whatisit.html>. You probably must change
your application name in order to avoid confusions.

Comment 42

[Benjamin Smedberg]

I have posted localization instructions at
http://www.mozilla.org/projects/firefox/l10n/ and one non-English locale (sl-SI)
is already part of the CVS tree. I will be updating the docs with more details
as I go, but I think this bug is fixed. You can build a localized build by
passing the --enable-ui-locale=ab-CD option to configure, or using a .mozconfig
option.

Comment 43

[Oscar Manuel Gómez Senovilla]

This bug should have been closed, because there were previous issues, as
commented in bug 245728, and in the url doesn't face this problem, apart that
seems win32-only, as if there weren't any other chances.

Comment 44

[Oscar Manuel Gómez Senovilla]

Two typos:

"This bug shouldn't have been closed"

and the bug is bug 254728