Terjemahan ini belum lengkap. Mohon bantu menerjemahkan artikel ini dari Bahasa Inggris.
Setelah hasil kerja keras anda dalam melokalisasi kami yakin bahwa anda tidak hanya ingin melihat hasil kerja anda tapi juga ingin memastikan bahwa itu tepat! Jika anda tidak begitu awam dengan kode, anda pasti khawatir akan merusak sesuatu (oops!). Sekarang kami akan menuntun anda melakukan test kualitas pekerjaan anda untuk memastikan anda berada di jalur yang tepat.
Jika anda melokalisasi halaman Mozilla, hasil pekerjaan anda akan ditampilkan segera setelah anda menyelesaikannya tanpa membutuhkan paket bahasa. Seperti halnya kasus ini, bagian dari pedoman ini tidak sepenuhnya dapat di aplikasikan oleh anda. Silahkan tekan tombol Next pada bagian paling bawah laman jika anda ingin melewati.
Untuk melihat hasil pekerjaan anda di Firefox (atau dalam aplikasi Mozilla yang lain), anda butuh paket bahasa yang terinstal pada direktori anda.
Manual & automated builds
Dengan menekan tombol, beberapa alat L10n (seperti Narro and Koala) secara otomatis membuat paket bahasa untuk anda. Jika anda menggunakan salah satu dari alat tersebut, silahkan menuju ke bagian Melihat pekerjaan anda, Sekarang mari menuju ke pembuatan paket bahasa anda sendiri secara manual.
Kita akan menggunakan file direktori berikut sebagai contoh:
your working directory (root)/ mozilla-aurora (en-US source, pulled from http://hg.mozilla.org/releases/mozilla-aurora )/ l10n-central (directory for L10n directories, one per L10n; often referred to as "l10n base")/ your-locale-code (a directory with your L10n files, in this example we'll use x-testing) Example:
Additionally, you will need to c
Please either follow the above structure closely or adjust the commands below according to your custom setup.
To copy this file to the appropriate directory, do the following:
- Navigate to your working directory from your command-line terminal (i.e., where you created the folder structure described above).
- Enter the following commands:
mkdir -p l10n-central/x-testing/toolkit/ cp mozilla-aurora/toolkit/locales/en-US/defines.inc l10n-central/x-testing/toolkit/defines.inc
Finally, you will need a file called
.mozconfig to proceed with manual builds. This file contains the necessary build instructions.
To create and configure this file, follow these instructions:
- Update the Mozilla source code:
$ cd mozilla-aurora
$ hg pull -u
- Enter the following command to create the
$ nano -w .mozconfig
- Enter the following lines in your
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../firefox-build ac_add_options --disable-compile-environment ac_add_options --with-l10n-base=../l10n-central # path relative to MOZ_OBJDIR ac_add_options --enable-application=[browser or mail]
You will need to specify which application you're localizing in the fourth line (e.g., for Firefox, that's
browser, Thunderbird would be
- Enter the following command to perform the configuration:
$ mach configure
- Once your command-line finishes spitting out the config command's output, navigate to the newy created directory:
$ cd ../firefox-build/browser/locales
Now you're ready to build! At this point you can choose between two build options. You can either:
- Create a langpack, which is installed on top of your Mozilla application, or
- Repack the application's binary (aka, a L10n repack), which allows you to install next to your existing Mozilla application installation and use separately.
Visit the links above to learn how to make these testing builds.
Testing your L10n & seeing your work
Now that you have your langpack or L10n repack, let's discuss seeing your work and testing it in the application.
Testing the langpack will put you one step closer to having your localization added to the L10n releases. Follow the steps below to test your localization:
- Install Aurora in your preferred language.
- Install the
.xpilangpack you just created (or exported).
- Set your language using the Quick Locale Switcher or Locale Switcher add-ons by navigating to Tools->Language->Your localization's language code.
- Restart your browser and start testing!
Now you should be able to see all of your work up to this point. Click here for guidelines on how to test your localization.
Don't lose your work!
You're work is SO important! We would really hate to see you lose any of it. After you test your localization, you should send it to a remote repository, which will serve as a backup for your work and will let others follow your progress. We're going to go through the process below.
The official localization teams use repositories at hg.mozilla.org. Before a team becomes official, we like to get the localizers comfortable with the Hg commands that allow for cloning, pulling, committing, and pushing work to an experimental repository. We use a web service called Bit Bucket to start the learning process.
Pushing to your repository
There are a couple of things you should take note of before you push to your repository:
- Make sure that your files have been encoded in Unicode without BOM (byte order mark).
- Remember that here you are pushing an entire directory, not a
.ziparchive file or an
The instructions below will help you learn how to use your Hg repository.
- After your new repository is created by the l10n-drivers, please visit the URL for your repo. We'll use x-testing here for our example. You can do this by entering the following URL into your browser:
- Now, navigate to your locale's directory on your local machine.
If you're using Koala, this should be located at
/path/to/your/koala.project/locale/3.6/x-testing, otherwise, it should be located at
In this directory, you should have an hg repository. You might have created it yourself by running
hg init or
hg clone or you might have had it created by Koala when you were setting up a new localization project. Also at this point, you shouldn't have any uncommitted changes (i.e., running the
hg status command should show nothing). Let's see what the last revision in this repository is.
- Enter the following command:
$ hg log -l 1
You should see an output similar to the one below:
changeset: 0:7c543e8f3a6a tag: tip user: Your Name <firstname.lastname@example.org> date: Mon Nov 23 18:08:25 2009 +0100 summary: Added search bar strings
- Now compare the local repository on your machine with the remote Hg repository by entering this command:
$ hg outgoing http://hg.mozilla.org/l10n-central/x-testing
hg outgoing command compares the two repositories and lists all changesets that are present locally, but not in the remote repository. These changesets will need to be "pushed" to the remote repository. You can expect to see output like this:
comparing with http://hg.mozilla.org/l10n-central/x-testing searching for changes changeset: 0:7c543e8f3a6a tag: tip user: Your Name <email@example.com> date: Mon Nov 23 18:08:25 2009 +0100 summary: Added search bar strings
- Let's now push this changeset. Enter the following command:
hg push http://hg.mozilla.org/l10n-central/x-testing
- Mercurial will connect to your repo and ask you to provide your account information (i.e., the username and the password).
real URL is http://hg.mozilla.org/l10n-central/x-testing pushing to http://hg.mozilla.org/l10n-central/x-testing searching for changes http authorization required realm: hg.mozilla.org HTTP user: your_id password:
After you enter your account information, the changeset will be pushed.
adding changesets adding manifests adding file changes added 1 changesets with 2 changes to 2 files bb/acl: your_id is allowed. accepted payload. quota: 979.7 KB in use, 150.0 MB available (0.64% used)
Your changeset has been successfully pushed to your repository!
As you begin to move through your translations, you should
commit the changes locally and
push your work to this experimental repository. For instance, if you have finished translating all the
.properties files in your
x-testing/browser/chrome/browser/ directory, then you should run these commands:
$ hg status $ hg commit -m "Translated browser/chrome/browser/" $ hg outgoing $ hg push http://hg.mozilla.org/l10n-central/x-testing
Note that due to the distributed nature of Hg,
hg commit saves the changes locally (i.e., in your computer's Hg repository). You can see the history of commits with
hg log. After doing
hg commit, you still need to send the changes to the remote repository. This is where
hg push comes in. This sends your commits to the remote repository.
Now you're ready to proceed to the release phase!