|
|
">
Localizing Mozilla
by Tao Cheng<tao@netscape.com>
Mozilla Localization newsgroup
Document History
-
02/28/2000:
-
02/23/2000: Add button to My Netscape Network Channel.
-
02/22/2000: Add Esperanto.
-
02/21/2000: Upload MozillaTranslator v3.1.
-
02/16/2000: Upload MozillaTranslator v3.
-
02/15/2000:
-
02/13/2000:
-
02/11/2000:
-
Add Malay and Ukrainian contributors.
-
Add description of MozExpTool from Jordi Mas.
-
02/10/2000:
-
02/09/2000: Add Glossary Files (contributed
by Daniel McGowan)
-
02/08/2000: Add Estonian translation.
-
02/07/2000:
-
02/04/2000: Add link to Norwegian lang pack.
-
02/03/2000: Add Bulgarian contributor.
-
02/02/2000:
-
One more M14 to come: Greek.
-
Add links to homepages submitted by contributors.
-
02/01/2000:
-
Register Dutch (NL) contributor. This makes the 20th
registered language.
-
Update M14 status.
-
Add Swedish contributor.
-
Add MPL licensing statement localization issue.
-
Update Configurable Chrome fix and usage.
-
01/31/2000:
-
Move 1999 History entries to the Bottom.
-
Upload German (de-AT) M13 language pack.
-
Add links to Mozilla download pages.
-
Register Russian contributor.
-
Register Portuguese (pt-PT) contributors.
-
Add index section; revamp the localization instructions.
-
Update FAQs.
-
01/28/2000: Upload Japanese M13 language pack (Release
Candidate).
-
01/27/2000: Add Mozilla Indonesian Effort info and M12 lang pack.
-
01/26/2000:
-
Post Czech M12 language pack.
-
Upload MozillaTranslator v.2 and notes from
the author.
-
Update Norwegian info.
-
Add QA for Hawaiian.
-
Add German Mozilla Translation link.
-
01/11/2000: Add Spanish (es-ES) contribution.
-
01/10/2000: Add Georgian and Spanish
contribution information.
-
01/03/2000: Update Czech, German
(M12 done), Polish (done; except Editor, Preferences,
acceptkey), and French status.
Goal
The purpose of this documentation is to give a brief introduction of how
to
localize the Mozilla browser client so that the reader does not need to
go through a lengthy document just to localize Mozilla into their favorite
languages.
Short term goal: Mozilla M14 (tree close: Feb 15, 2000; on the wire: Feb.
18, 2000)
Utilize the contributed localization tools to localize the Mozilla client
M14 build into all the sixteen registered languages.
As of now, we are at the end of M13 milestone development phase. In
a few days, M13 will be on wire for public consumption. Since this is the
first public release after Mozilla Alpha Release, lots features and improvement
have been checked in. It is safer to expect that the milestone release
after M13 be more stable and robust. Therefore, I'd like to invite you
to localize the M14 and ship all languages in the same time frame as the
English build. In other words, let's ship all our language packs within
15 days, after the US build ships. Although, nothing could prevent us from
even shipping language packs simultaneously with the US build!
How to localize
The following sections outline how to localize the Mozilla client:
-
Registering as MLP contributor(s).
-
Download a build.
-
Use Localization/Leveraging tool and glossary files.
-
Work on the files.
-
QA your work.
-
Packaging them.
-
Submitting.
Registering as a MLP contributor
Just send a message to the newsgroup
and CC Tao, your name(s)
will be inserted into MLP status table. Other information such as links
to your website will be inserted into the table shall they are provided.
Where to Get Mozilla builds
You can download a milestone build here
http://www.mozilla.org/projects/seamonkey/release-notes/index.html
or a nightly build here
ftp://ftp.mozilla.org/pub/mozilla/nightly/
To synchronize with the Mozilla release schedule, contributors are encouraged
to submit milestone builds which most people use. In the future, we plan
to push localized builds and/or language packs to Mozilla's ftp sites and
provide links from the Mozilla milestone build download page.
Use a Localization/Leveraging tool
Use localization/leveraging tools to improve our productivity.
It'd be a waste of time and error prone if we need to localize each build
from scratch. With the MozillaTranslator or MozExpTool, you can identify
which strings are new and need to be localized.
Glossary Files (contributed by Daniel
McGowan)
Here are a list of glossary files from previous releases (including Communicator
4.x) for reference. Translation consistency and quality can be greatly
improved if there are glossary files for reference.
These files are all tab delineated text files. They can be imported
into and sorted/ordered in Excel or StarCalc (part of StarOffice
- available in en, de, fr, it, es, nl, bp and sv).
What needs to be localized
In Mozilla, all UI resources are located in the "chrome/" directory of
the install directory. Localizable files are placed under "packageType/locale/locale_name"
directories where "packageType" is one of the UI components such as the
"addressbook", "bookmarks", "navigator", etc... and "locale_name"
is the language into which Mozilla is localized.
There are three types of files that need to be localized in Mozilla:
-
The DTD (*.dtd) files. This document
explains our strategy of localizing XUL files. A typical DTD file contains
a list of entities that need to be localized. An entity declaration looks
like this:
<!ENTITY browserCmd.label "New Browser Window">
The entity with name/key, "browserCmd.label", has the entity value, "New
Browser Window". The entity value is what
needs to be localized. Note the entity name, "browserCmd.label",
is self-explanatory: it's the label string of the "browserCmd" menu item.
The XUL writers or Localization engineers also try to include as many comments
as possible in the DTD files. Such comments are placed right above the
entity declaration and are marked as
<!-- LOCALIZATION NOTE entity_name: comments -->
For example,
8<!--
LOCALIZATION NOTE throbber.url: Do NOT localize all the URL -->
9<!ENTITY throbber.url "http://www.mozilla.org">
Note that, UTF-8 is the default document
encoding for XUL/RDF/XML files in Mozilla. Translated strings shall be
in UTF-8 encoding unless otherwise indicated in the text declaration section.
Native encodings such as EUC, SJIS, and others can be converted into UTF-8
by a utility program, nsconv(.exe) shipped with the client in the same
directory as apprunner(.exe). The usage:
nsconv -f source_encoding -t target_necoding source_file target_file
-
The Property (*.properties) files. Property files
are used as the data storage for the String
Resources bundle mechanism. String resources in property files appear
in the form of
name=value
The "value"
part is what needs to be localized. Localization notes are also added where
necessary. For example,
25
#-----------------------------------------------------------
26 # LOCALIZATION NOTE
InstallFile:...
27 #-----------------------------------------------------------
28 InstallFile=Installing: %s
29 ReplaceFile=Replacing: %s
Please note that "escape-unicode" is the only accepted
document encoding in property files. You can use your favorite encoding
during translation and convert it to escape-unicode via the "native2ascii"
utility program available on most Unix systems. Java SDK also includes
"native2ascii". In addition, nsconv(.exe) mentioned earlier can be used
to convert native encoding to escape unicode. For escaped-unicode, use
the name "x-u-escaped".
-
If you're a purist and would like to see the localized client exhibit
platform specific characteristics, there are two platform specific files:
chrome/global/locale/en-US/platformGlobalOverlay.dtd
chrome/global/locale/en-US/platformDialogOverlay.dtd
They contain command/menuitem labels and key bindings that are
considered platform dependent:
::::::::::::::
platformDialogOverlay.dtd
::::::::::::::
<!-- unix -->
<!-- OK Cancel Buttons -->
<!ENTITY okButton.label "OK">
<!ENTITY cancelButton.label "Cancel">
::::::::::::::
platformGlobalOverlay.dtd
::::::::::::::
<!-- unix -->
<!-- LOCALIZATION NOTE : FILE Do not translate all the Cmd.key and
accesskey -->
<!ENTITY closeCmd.label
"Close">
<!ENTITY closeCmd.key "W">
<!ENTITY closeCmd.accesskey "c">
<!ENTITY quitApplicationCmd.label "Quit">
<!ENTITY quitApplicationCmd.key "Q">
<!ENTITY quitApplicationCmd.accesskey "q">
<!ENTITY redoCmd.label
"Redo">
<!ENTITY redoCmd.key "Z">
<!ENTITY redoCmd.accesskey "r">
Customizing them on per platform basis makes the product more user-friendly.
-
The chrome registry,
"chrome/registry.rdf".
Localized files for a package type shall be placed under the associated
"locale_name" subdirectory. In order for the Mozilla client to pick up
the localized files, the name entries (in-between <name>...</name>)
in the chrome registry must be replaced with the "locale_name". (10/29/99)
Please note
that the registry file and the implementation of the Configurable Chrome
has been re-architectured. The new way of configurating the chrome registry
follows.
Please create a "chrome.rdf" file with such content:
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://chrome.mozilla.org/rdf#">
<RDF:Description
about="chrome://addressbook/locale/">
<name>en-US</name>
</RDF:Description>
</RDF:RDF>
Replace the "addressbook' part with the package
name, such as global, navigator, etc..., and the "en-US" part with the
locale name (where you put the translated files). And then, drop it into
chrome/[package]/locale. You need one chrome for each package. If
you are using MozillaTranslator v.2, the
"chrome.rdf" are created automatically. This shall work on builds after
2000-01-28.
QA the localization results
This is to have the language pack reviewed and tested
so that bugs or flows can be identified beforehand and thus avoid respinning
of the localized builds. Ideally, the QA shall not be the author
since the author tends to go through paths that she/he is familiar with.
Packaging
There are couple of ways of packaging the localization
results
-
As an individual language pack. In other word, pack
all files in chrome/[package]/locale/[locale-name] directories. This will
result in a minimum size of deliverable that can be downloaded and installed
in the end user's isntall directory. Before the re-architecturing of the
Configurable Chrome feature is settled, please leave localized files in
the en-US directories.
-
As a complete localized build in a big zip (or gz)
file. All the end users need to do is to download and unzip the build into
their local directories.
-
A localized installer build. A complete professional
quality installation process. This relies on the availability of a localizable
xpinstaller. As of now, this is not feasible yet; but, it is the ultimate
goal.
Submitting
After you're done, please post them to the newsgroup
or send it to me. I'll push them up to Mozilla Org. for downloading. (Checking
them into the source tree does not make them a language pack yet.)
We are also planning to push the localized build up to Mozilla.org's
FTP site. Once we push the localized builds up to the FTP sites, I expect
more people to download and use them since the FTP download sites get more
visibility than the MLP's home page.
Localization/Leveraging Tools
Localization tools contributed from the net:
Notes
-
MozExpTool. A VisualC++ based project. It is designed to address the localization
and leveraging need of languages in single-byte charsets. Both source code
and WIN32 binary are available. More detailed technical spec can be found
here, MozExpTool
0.94.
MozExpTool allows you to create text files (we call them glossaries)
from dtd/xul files that you can give them to translators then they do not
have to mess around with dtd/xul files. When the translators have finished
their translations you can reimport them into the dtd/xul files.
A part of helping the simplifying the translator's work, MozExpTool
allows to leverage (recover previous translations). You can easily create
a glossary file from the old version, and then reimport it to the set of
dtd/xul files. When leveraging, we take in account the context of the translation,
that is, the file that is coming from and the name of the entity.
-
MozillaTranslator is a GUI-based Localization and Leveraging tool written
in Java. Although still in development stage, it is suitable for both single-byte
and double-byte charsets including all Latin-1, 2, and CJK (Chinese, Japanese,
and Korean): nearly all languages covered by Unicode. The package is available
as a single jar file together with a DOS batch driver. JDK.1.2.2 is needed
to run the program.
MozillaTranslator
See details here.
MozExpTool 0.94
This new version has been used sucesfully to leverage the strings to build
13, and I has been used for a couple of weeks without any problem.
What's new in version 0.94?
-
Line feeds, return lines and tabs within entities definitions are handled
properly. We use now the standard \n, \r, and \t to refer to them.
-
If there are comments in the DTD files they are included in the glossaries
when they are exported. This helps to the translators that
work with the glossary files.
-
The parser code has been move to a class.
-
Small bug fixes.
Mozilla Localization Project (MLP)
This page
explains how you can contribute your localization work to Mozilla and the
current status of the Mozilla Localization Project.
The following table summarizes the current contributions
of Mozilla (5.0) localization. Contact the original contributors or Tao
Cheng if you have problems using these language packs.
| Languages (locale name) - 40 |
Contributor(s) |
Localized Build or Language Packs |
QA |
Notes |
| Arabic |
Hassan Aurag |
|
|
|
| Bosnian (bosnian-BA) |
Adnan
Selimovic , Isan
Selimovic , Jasmin
Azemovic |
|
|
-
mozilla-win32.zip
-
bosnian.zip
-
Note from Adnan
|
| Bulgarian |
Bozhan
Boiadzhiev |
|
|
|
| Catalan |
Jordi Mas |
(M14) |
|
|
| Chinese - Simplified (zh-CN) |
Jack Lee,
Wang Jian,
Xiaodan Zhu,
Weiping Liu |
(M14) |
|
|
| Chinese - Traditional (zh-TW) |
Wan-Teh Chang |
|
|
|
| Czech |
Jan Pokorny
Jiri
Znamenacek |
|
|
-
Zipped beneath \bin\chrome.
-
Overwrite en-US directories.
-
Please direct comments to Jan
Pokorny
|
| Danish (da-DK) |
Henrik Lynggaard |
|
|
The zip file. |
| Dutch (NL) |
Jan Fabry |
(M14) |
|
Dutch
translation web site |
| English (en-UK) |
Nathan
Kirkham , Alastair
Moore |
|
|
|
| Esperanto |
Eduardo |
|
|
|
| Estonian |
Kristjan
Zink |
|
|
|
| Finnish |
Raine Rapo,
Arto Laitinen |
|
|
|
| French |
Olivier Bailly,
Jean-Claude Ben,
David Bellot,
Rither
|
(M12) |
|
|
| Georgian |
Gia Shervashidze |
|
|
|
| German |
Robert
Kaiser |
|
|
|
| Greek |
Kyriakos
K. Skafas |
(M14) |
|
|
| Hawaiian |
Keola
Donaghy |
(M14) |
Keiki
Kawai'ae'a |
|
| Hebrew |
Zvi Nachmani |
(M14) |
|
|
| Hungarian |
XYBeR |
|
|
|
| Indonesian |
Dan Howard
, Albert Sutojo, and Endro
Koesno |
M12: Full
build or language
pack only (or here) |
Albert Sutojo and Endro
Koesno |
Related
link |
| Italian |
Andrea,
Daniele Curto,
Daniele Medri,
Andrew,
Fabio,
Giovanni
|
|
|
|
| Japanese |
Yuta
Taniguchi
, Ryoichi Furukawa,
KazuYamamoto |
Japanese language pack
|
|
The "en-US" pack overwrites all files under "locale/en-US", while the
"ja-JP" pack places translated files under "locale/ja-JP". Related
information of Japanese language pack. |
| Malay (ms-MY) |
Ranjinath |
|
|
|
| Norwegian (Bokmål) |
Magnus Sulland |
|
|
|
| Norwegian (nynorsk) |
Karl
Ove Hufthammer |
|
|
See details here: http://home.no.net/huftis/mozilla.html |
| Plautdietsch (Mennonite Low German) |
Chris Cox |
|
|
|
| Polish |
Marcin
Jagodzinski |
|
|
(done; except Editor, Preferences, acceptkey) Related
documents. |
| Portuguese (pt-BR; Brazil) |
Andrei Bosco
, Marcos
Paulo Hauer, Hebert
Silva, Ricardo Loiola,
Ricardo
Guimarães |
|
|
|
| Portuguese (pt-PT; Portugal) |
Francisco
Castanheiro & Pedro
Figueira |
(M14) |
|
Portuguese
Mozilla homepage |
| Romanian |
Vlad Gavrila
|
|
|
|
| Russian |
Dmitry Sivachenko,
Pedro Rosa,
Aleksey Titorenko (Software Project Department of Stack Ltd) |
|
|
|
| Serbian |
Zeljko Cvrkotic |
|
|
|
| Spanish (es-CO) |
Silvio
Andrés Salazar Martínez |
|
|
|
| Spanish (es-ES) |
Alexander
Kadlec Aguirre (NAVE
project) |
|
|
|
| Swedish (sv-SE) |
Fredrik |
(M14) |
|
|
| Thai |
Isiya
Paireepairit |
|
|
Partial translations for Navigator windows only. |
| Turkish |
Huseyin Killic |
|
|
|
| Ukrainian (uk-UA) |
Sergey |
|
|
|
| Welsh |
Kevin Donnelly |
|
|
|
Notes
-
The language packs are portable across platforms.
-
mozilla-win32.zip
contains the Mozilla executable, English language files, and Bosnian language
files. By default, the UI language is in Bosnian.
-
bosnian.zip contains
only the language files needed for Bosnian. You need to unzip them into
chrome/ directory and change all "en-US" name entries to "da-DK" in chrome/registry.rdf
to pick up these UI strings.
-
Used only ASCII characters in bosnian-BA DTD
files, because by the time of M8.5 some windows crashed when special UNICODE
characters were used. I wanted that Mozilla runs as good as possible, so
I converted all our special characters into ASCII ones. This method is
used allot here. To display our characters people must have PANEURO version
of Windows 9x or NT. Our software is mostly without this special characters.
Plan to change this for the next release.
-
This zip file contains only the language files
needed for Danish. You need to unzip them into chrome/ directory and change
all "en-US" name entries to "da-DK" in chrome/registry.rdf to pick up these
UI strings.
Getting Access Privilege to the tree
Localization contributors and translators will need CVS access privilege
to check in localization work into Mozilla. Here is the link to the page
that describes the tree rules and how to obtain a CVS account .
http://www.mozilla.org/hacking/
To accommodate localization related files but avoid breaking the build
process of other modules, there will be a dedicated directory, "l10n/",
created under the top directory of the Mozilla tree, "mozilla/". See next
section for details.
The Directory structure for Localization related
work
The following tree structure is proposed to accommodate all localization
related work in the Mozilla tree.
-
The directory structure. Share the CVS repository with the Mozilla
tree but place localization related files under separate directory. Tague
Griffith recently created a new directory, "l10n/" to accommodate the open
source L10n tools contributed from the net. The tools will be checked in
under a subdirectory, "l10n/tools/". We can have the language specific
files placed under a subdirectory, "l10n/lang/", in parallel with the tools.
And then there is another sub-directory, "l10n/builds", which accommodates
various build related files. The directory structure looks like this:
mozilla/
[other modules]
[...]
l10n/
tools/
mozexptool/
mozillatranslator/
etc...
lang/
addressbook/locale/
bosnian-BA/
da-DK/
da-DK-vendor1
ja-JP-vendor1
ja-JP-vendor2
etc...
bookmarks/locale/
bosnian-BA/
da-DK/
da-DK-vendor1/
ja-JP-vendor1
ja-JP-vendor2
etc...
[other package types, etc...]
builds/
[release team's stuff]
-
Pulling the tree. The current Mozilla build process does not pull
"l10n/". Therefore, other module developers will not pull "l10n/" unless
they explicitly do so. This addresses the concern about tree pulling time
and wasted disk space problems. However, during the development cycle,
we still have the choice of making the pulling of l10n/ be the default.
-
The build script. The build script of the localized client can be
setup to be part of the daily build or run as a standalone script.
The advantages of this approach follow.
-
Since l10n is not part of the daily Mozilla build pull, localization checkins
(under "mozilla/l10n") are not restricted by the Tinderbox rules and therefore
are not on the hook.
-
Net developers can be granted access privilege and work on the open source
tree directly.
Note that this by no means encourages people to abuse the "mozilla/l10n"
directory. All CVS checkin rules still apply. Courtesy to peer contributors
and respect for module ownership is required in the open source community.
References and more information...
FAQ of MLP
-
Mozilla Open Source client v.s. Netscape branded client
There will be planned beta releases (and the final RTM) of Netscape
branded builds. Netscape might choose to localize some or all of them into
languages such as German,French, Japanese, etc... See Q/A sessions below for more
information.
-
What license statement, ULP, NPL, or MPL , shall
be inserted into the translated resource files such *.dtd and *.properties?
To licence your work under the MPL you should include a boilerplate
licence in a comment at the beginning of each file.
New files checked into the tree need to have licensing text added to
the top. Here is table containing versions of this boilerplate text preformatted
for various different types of files.
Please always use these templates when adding files to the tree: they are
carefully formatted so that future updates to the boilerplate will be easy
to make.
-
Sample MPL as follows.
"The contents of this file are subject to the Mozilla Public License
Version 1.1 (the "License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.mozilla.org/MPL/
Software distributed under the License is distributed on an "AS IS"
basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the
License for the specific language governing rights and limitations under
the License.
The Original Code is Mozilla Communicator client code, released March
31, 1998.
The Initial Developer of the Original Code is Netscape Communications
Corporation. Portions created by Netscape are Copyright (C) 1998-2000 Netscape
Communications Corporation. All Rights Reserved.
Contributor(s): ____________________________________."
-
Shall we localize the license?
No. The boilerplate text should appear as-is, in English. However
I think that a localized comment following the boilerplate that points
to a translation would be fine provided that the following disclaimer
is provided with the translation.
In places where the NPL, MPL or boilerplate are translated, please
place a translation of the following language at the beginning of
the translated license:
"The controlling language of this agreement is English. The following
[lang] language translation has been provided for your convenience only."
Substitute your language for "[lang]".
-
Can contributors distribute the localized version?
Yes, as long as you comply with the MPL, there shall be no problem.
-
Into what languages will the Netscape branded version be localized?
Netscape branded version will be localized at least into German, French
and Japanese. Future plans for other languages will be announced at Netscape's
discretion.
-
Is Netscape going to release localization work in Netscape branded version
to the open source tree, Mozilla? How about OEMs'?
Netscape localized files will be posted into mozilla in the languages that
we localize as we have them available.
-
Will we incorporate the contributed translations into the Netscape branded
version?
Currently, Netscape and it's partners are producing the language versions
we need to support its business strategies. If those strategies change,
Netscape may choose to look to the work being done on mozilla.org.
-
How do we deal with conflicts such as Mozilla version vs Netscape version
of the same languages?
Mozilla and Netscape branded product will be two different products; open
source developers can have their localized files checked into mozilla tree
without conflicting with Netscape branded product.
Document History - 1999
-
12/23/1999: Upload Japanese translation for M12.
-
12/20/1999: Update German referenece build info. Add Catalan
and Norwegian.
-
12/17/1999: Add Brazilian and German.
-
12/14/1999: Add Hawaiian translation info.
-
12/03/1999: Add Greek translation info.
-
12/02/1999: Add Mozilla M11 based translation for Japanese.
Add Polish translation information.
-
11/10/1999: Add partial translation for Thai. Also,
updated Danish pack status.
-
10/29/1999: MLP: add Thai and Czech contacts
-
10/18/1999: add References and more information...
section.
-
10/15/1999: Add table to summarize the current
contributions.
Add link to Jordi and Henrik's tools.
-
10/01/1999: Minor corrections
-
09/27/1999: Add FAQ section.
09/23/1999: First draft.
|
