Provide information how to localize Firefox

RESOLVED FIXED in Firefox1.0beta

Status

()

Firefox
General
P1
critical
RESOLVED FIXED
14 years ago
6 years ago

People

(Reporter: MMx, Assigned: Benjamin Smedberg)

Tracking

({fixed-aviary1.0, intl})

unspecified
Firefox1.0beta
fixed-aviary1.0, intl
Points:
---
Bug Flags:
blocking-aviary1.0PR +
blocking-aviary1.0 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
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.
(Reporter)

Updated

14 years ago
Flags: blocking0.9?
Hardware: Macintosh → All
Target Milestone: --- → Firefox0.9
confirming.
and please, give us a few days between stabilizing locales and releasing 0.9.

Comment 2

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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.
Keywords: intl

Comment 7

14 years ago
(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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
(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.
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

14 years ago
(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

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
Created attachment 150669 [details]
screen shot

Screenshot by "firefox -ProfileManager -UILocale ja-JP -contentLocale JP"
(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.   

Created attachment 150670 [details]
Screenshot of error

Screenshot of error when selecting Options from context menu.

Comment 20

14 years ago
(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.
(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

14 years ago
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.
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

14 years ago
Moving blocking0.9? to blocking1.0?
Flags: blocking0.9? → blocking1.0?
Summary: Provide information how to localize Firefox 0.9 → Provide information how to localize Firefox

Comment 25

14 years ago
(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

14 years ago
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).
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.
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.
> 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.
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!
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

14 years ago
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."
(Reporter)

Comment 33

14 years ago
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

14 years ago
Localization is very important to us.
Flags: blocking1.0? → blocking1.0+
Priority: -- → P1
Target Milestone: Firefox0.9 → Firefox1.0beta

Comment 35

14 years ago
(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.
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

14 years ago
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 chofmann@mozilla.org with ideas for
discussion and specific bug numbers that are hindering translation efforts.  Asa
and I will also be watching this bug.
(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 chofmann@mozilla.org 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.
Created attachment 151642 [details]
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)
(Assignee)

Comment 40

14 years ago
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$cvk1@ripley.netscape.com

Once I get the en-US directory working properly, I will post more detail
directions for localizers.
Assignee: firefox → bsmedberg
(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.
Flags: blocking-aviary1.0RC1+
(Assignee)

Comment 42

14 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
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.
Two typos:

"This bug shouldn't have been closed"

and the bug is bug 254728

Updated

13 years ago
Keywords: fixed-aviary1.0
You need to log in before you can comment on or make changes to this bug.