Bugzilla en français

Get The Source Files

Obtain the source files from Bugzilla.org site

Uncompress the tarball with your favorite tool in an empty directory. You should have the following tree structure (note: all subdirectories and files are not detailed here):

|-- Bugzilla
|-- contrib
|-- docs
|    |-- en
|-- extensions
|    -- BmpConvert
|   |-- Example
|   |   |-- docs
|   |   |   `-- en
|   |   |-- lib
|   |   `-- template
|   |       `-- en
|   |-- MoreBugUrl
|   |   |-- lib
|   |   `-- template
|   |       `-- en
|   |-- OldBugMove
|   |   |-- lib
|   |   `-- template
|   |       `-- en
|   `-- Voting
|       |-- template
|       |   `-- en
|-- images
|-- js
|-- template
|   `-- en

All the localizable content are located in the highlighted directories, so you should only keep the following:

|-- docs
|    |-- en
|-- extensions
|   |-- Example
|   |   |-- docs
|   |   |   `-- en
|   |   `-- template
|   |       `-- en
|   |-- MoreBugUrl
|   |   `-- template
|   |       `-- en
|   |-- OldBugMove
|   |   `-- template
|   |       `-- en
|   `-- Voting
|       |-- template
|       |   `-- en
|-- template
|   `-- en

Now, rename all the en subdirectories with your locale code. You can pick the locale code matching your language in this wiki page.

For instance, you can use fr for French or ca for Catalan. You can also use a four-letter locale code: pt-BR for Brazilian Portuguese or zh-CN for Chinese (Simplified).

Files To Be Localized

There are different types of files to be localized:

*.tmpl files:

These files are the templates. There are used to generate with Template Toolkit the html pages of the user interface of Bugzilla application. There are located in the extensions and template subdirectories.

*.rst files:

These files are used to generate the documentation files in different formats. There are written using ReStructuredText. There are located in the docs and extensions/Example/docs/en/rst subdirectories.

README:

This file is in plain text and located in Bugzilla's root directory. It is a short document explaining how to install and run Bugzilla quickly.

bzLifecycle.xml:

It is a source xml file generated with the diagramming tool Dia. It is used to generate the picture of the different states in a bug lifecycle.

strings.txt.pl:

It is a Perl file. It is used to display information or error messages during Bugzilla's setup and is located in the template/fr/default/setup directory.

Localizing The Templates

Currently, these templates contain code and localizable strings mixed together that makes the localization of Bugzilla a bit difficult. What is to be localized and what is not?

IMPORTANT: Use an UTF8 compliant editor like Gedit, Kate or Emacs under GNU/Linux systems or Notepad++ under Windows systems and localize the templates using UTF8 encoding. You can also use Komodo Edit which has great syntax highlighting for Template Toolkit files.

Here are some examples to help you localizing the right stuff. A good idea is to start with the localization of /template/en/default/global/variables.none.tmpl. This file contains several terms that will be substituted all around the templates files. You can see in this file lines like these:

[%# This Source Code Form is subject to the terms of the Mozilla Public
  # License, v. 2.0. If a copy of the MPL was not distributed with this
  # file, You can obtain one at http://mozilla.org/MPL/2.0/.
  #
  # This Source Code Form is "Incompatible With Secondary Licenses", as
  # defined by the Mozilla Public License, v. 2.0.
  #%]

DO NOT translate text located between [%# and #%]: the text inside is comment.

[% terms = {
  "bug" => "bug",
  "Bug" => "Bug",
  "abug" => "a bug",
  "Abug" => "A bug",
  "ABug" => "A Bug",
  "bugs" => "bugs",
  "Bugs" => "Bugs",
  "zeroSearchResults" => "Zarro Boogs found",
  "bit" => "bit",
  "bits" => "bits",
  "Bugzilla" => "Bugzilla"
  }
%]

DO NOT translate terms here. What is to be translated here, is the word between the quotes after =>, as highlighted in red above.

These terms will be used in the templates. Whenever you see expressions like &terms.ABug or &terms.bugs in templates, they will be replaced in the user interface with the value you put in this file.

Another file that is used by several templates is /template/en/default/global/field-descs.none.tmpl. You can see there lines like these:

[% IF in_template_var %]
  [% PROCESS "global/value-descs.none.tmpl" %]
  [% SET vars.value_descs = value_descs %]
  [% SET vars.terms = terms %]

  [%# field_descs is loaded as a global template variable and cached
    # across all templates--see VARIABLES in Bugzilla/Template.pm.
    #%]
  [% vars.field_descs = {
    "[Bug creation]"          => "[Date de création du $terms.bug]",
    "actual_time"             => "Heures actuelles",
    "alias"                   => "Alias",
    "assigned_to"             => "Responsable",

DO NOT translate here PROCESS or USE. As a general rule, never translate capitalized words enclosed between [% and %]. As previously, translate the word after the =>.

Now, you can start translating the other templates. Some other examples of what needs to be translated:

[% title = BLOCK %]Delete Component '[% comp.name FILTER html %]'
of Product '[% product.name FILTER html %]'
  [% END %]

[% PROCESS global/header.html.tmpl
  title = title
%]

<table border="1" cellpadding="4" cellspacing="0">
<tr bgcolor="#6666FF">
  <th valign="top" align="left">Field</th>
  <th valign="top" align="left">Value</th>
</tr>

Localized template:

[% title = BLOCK %]Supprimer le composant « [% comp.name FILTER html %] »
du produit « [% product.name FILTER html %] »
  [% END %]

[% PROCESS global/header.html.tmpl
  title = title
%]

<table border="1" cellpadding="4" cellspacing="0">
<tr bgcolor="#6666FF">
  <th valign="top" align="left">Champ</th>
  <th valign="top" align="left">Valeur</th>
</tr>

You will encounter many buttons you will want to localize. These are looking like this:

  <input type="submit" id="create" value="Add">
  <input type="hidden" name="action" value="new">
  <input type="hidden" name='product' value="[% product.name FILTER html %]">
  <input type="hidden" name="token" value="[% token FILTER html %]">

Whenever you see this, the only line that needs to be localized is the one with type="submit". DO NOT translate lines with type="hidden":

  <input type="submit" id="create" value="Ajouter">
  <input type="hidden" name="action" value="new">
  <input type="hidden" name='product' value="[% product.name FILTER html %]">
  <input type="hidden" name="token" value="[% token FILTER html %]">

Other common lines through the templates are text enclosed between an opening and a closing tag:

<td valign="top">Description du produit :</td>

<td valign="top">[% IF product.disallow_new %]Oui[% ELSE %]Non[% END %]</td>

  <a title="Liste des [% terms.bugs %] pour le composant « [% comp.name FILTER html %] »"
     href="buglist.cgi?component=[% comp.name FILTER url_quote %]&product=
          [%- product.name FILTER url_quote %]">[% comp.bug_count %]</a>

Caveats

[% %] and [%+ %]

Generally, you should follow the English model, but if you need to change the order of [% %] in a line, you should be aware of those rules: when two [% %] members are following each other, the second member will not be separated with a space from the first one, even if you separate them with a space:

  [% ELSIF message_tag == "bug_duplicate_of" %]
    This [% terms.bug %] has been marked as a duplicate of [% terms.bug %] [% dupe_of FILTER html %]

For instance, the previous line of code will display in the browser as:

This bug has been marked as duplicate of bug12345

Instead you should add a "+" sign in the second member:

  [% ELSIF message_tag == "bug_duplicate_of" %]
     This [% terms.bug %] has been marked as a duplicate of [% terms.bug %] [%+ dupe_of FILTER html %]

Will then be displayed as:

This bug has been marked as duplicate of bug 12345

This is the same when a [% %] member is at the beginning of a new line:

        [% IF groups_added_to.size %]
          <li>
            The account has been added to the
            [% groups_added_to.join(', ') FILTER html %]
            group[% 's' IF groups_added_to.size > 1 %].
          </li>
        [% END %]

The previous code will be shown as:

The account has been added to thebz_sudo_protect group.

You should instead put a "+" sign:

        [% IF groups_added_to.size %]
          <li>
            The account has been added to the
            [%+ groups_added_to.join(', ') FILTER html %]
            group[% 's' IF groups_added_to.size > 1 %].
          </li>
        [% END %]

So that the sentence is displayed as:

The account has been added to the bz_sudo_protect group.

If one wants to localize the previous example into French for instance, the words order is not correct and the members have to me moved. The member [% groups_added_to.join(', ') FILTER html %] will actually display the name of one group or several group names separated with a comma and a space (', '). The member [% 's' IF groups_added_to.size > 1 %] will add an "s" to the word "group" if there is more than one. In French, the group name should be put after the term "group" and words need to be declensed when plural is used. That would give for instance the following:

        [% IF groups_added_to.size %]
          <li>
            Le compte a été ajouté
            [% IF groups_added_to.size > 1 %]
            aux groupes[% ELSE %]au groupe[% END %][%+ groups_added_to.join(', ') FILTER html %].
          </li>
        [% END %]

The browser would then display for one group:

Le compte a été ajouté au groupe bz_sudo_protect

And for several groups:

Le compte a été ajouté aux groupes bz_sudo_protect, canconfirm, editbugs

Double quotes and single quotes

You should take care of the usage of the quotes in certain cases. You shouldn't put quotes inside a pair of quotes. The following example will break the user interface:

  [% ELSIF message_tag == "buglist_adding_field" %]
    [% title = "Adding field to search page..." %]
    [% link  = "Click here if the page "does not" redisplay automatically." %]

Instead, you can escape them with a backslash ("\"):

  [% ELSIF message_tag == "buglist_adding_field" %]
    [% title = "Adding field to search page..." %]
    [% link  = "Click here if the page \"does not\" redisplay automatically." %]

Or you can substitute the surrounding double quotes with single quotes:

  [% ELSIF message_tag == "buglist_adding_field" %]
    [% title = "Adding field to search page..." %]
    [% link  = 'Click here if the page "does not" redisplay automatically.' %]

Declensions

English only deals with one plural form and has no declension. Your locale might need to implement declensions and reorder words inside a sentence. WARNING: this is a bit tricky and making mistake here will break your Bugzilla localization (i.e. some features might not function when your locale package will be installed).

Let's say we have the following:

  [% IF !Param("allowbugdeletion") %]
  <p>
    Sorry, there

    [% IF comp.bug_count > 1 %] 
      are [% comp.bug_count %] [%+ terms.bugs %] 
    [% ELSE %]
       is [% comp.bug_count %] [%+ terms.bug %] 
    [% END %]

    pending for this component. You should reassign

    [% IF comp.bug_count > 1 %]
       these [% terms.bugs %]
    [% ELSE %]
       this [% terms.bug %]
    [% END %]

    to another component before deleting this component.
  </p>
  [% ELSE %]

Here, the following expression comp.bug_count obviously gives the count number of bugs for a component. IF comp.bug_count > 1 means "if there are more than one bug".

Let's say your language has to deal with three plural forms and that the terms "bug" and "pending" should be declensed as well.

First, you'll have to populate the /template/en/default/global/variables.none.tmp file with the declensions for "bug", which would give something like:

[% terms = {
  "bug0" => "declension for zero bug",
  "bug" => "declension for one bug",
  "bug2" => "declension for two bugs",
  "bug3" => "declension for three bugs",
  "bugs" => "declension for more than three bugs",

Then, the previous code should look like:

  [% IF !Param("allowbugdeletion") %]
  <p>
    Sorry, there

    [% IF comp.bug_count > 3 %] 
      are [% comp.bug_count %] pending [% terms.bugs %] 
    [% ELSE %]
      [% IF comp.bug_count == 0 %] 
       is [% comp.bug_count %] pending [% terms.bug0 %] 
    [% ELSE %]
      [% IF comp.bug_count == 1 %] 
       is [% comp.bug_count %] pending [% terms.bug %]
    [% ELSE %]
      [% IF comp.bug_count == 2 %] 
       are [% comp.bug_count %] pending [% terms.bug2 %]
    [% ELSE %]
      [% IF comp.bug_count == 3 %] 
       are [% comp.bug_count %] pending [% terms.bug3 %] 
    [% END %]

    for this component. You should reassign

    [% IF comp.bug_count > 1 %]
       these [% terms.bugs %]
    [% ELSE %]
       this [% terms.bug %]
    [% END %]

    to another component before deleting this component.
  </p>
  [% ELSE %]

$terms.foo

As seen previously, term substitutions are made across all templates files with help of *.none.tmpl files, which are:

template/en/default/global/field-descs.none.tmpl
template/en/default/global/variables.none.tmpl
template/en/default/global/value-descs.none.tmpl
template/en/default/global/reason-descs.none.tmpl
template/en/default/global/setting-descs.none.tmpl
template/en/default/bug/field-help.none.tmpl

These variables appear in the template files under three different forms: $terms.foo, ${terms.foo} and [% terms.foo %] (Note: If someone could explain me briefly why and when, I would add it there ☺).

During your localizing contribution, you will have to reorganize sentences, and sometimes a variable of the form $terms.foo would end at the end of a sentence which is ended with a dot, like this:

  defaultplatform => "Plateforme qui est pré-sélectionnée dans le formulaire de soumission " _
                     "de $terms.bug.<br> " _
                     "Vous pouvez laisser ce champ vide : " _
                     "Bugzilla utilisera alors la plateforme indiquée par le navigateur.",

If you let it that way, the substitution would not take place and the result in the user interface might be quite weird. Instead, change the form $terms.foo, for the form ${terms.foo}, like this:

  defaultplatform => "Plateforme qui est pré-sélectionnée dans le formulaire de soumission " _
                     "de ${terms.bug}.<br> " _
                     "Vous pouvez laisser ce champ vide : " _
                     "Bugzilla utilisera alors la plateforme indiquée par le navigateur.",

b[% %]ug

Once and a while you would find something like:

A b[% %]ug on b[% %]ugs.debian.org.

You remember that the file variables.none.tmpl holds the substitution for different terms. It is useful if you want to replace all over the user interface for instance the term "bug" with the term "ticket". The release process of Bugzilla has a script that parses all the templates to check if you wrote the bare word "foo" instead of "$terms.foo".

In the example above, we really want to write the term "bug" and we neither want it to be substituted afterwards nor being warned by the checking.

As far as I know, for the moment this checking is working only for the English terms —bug, bugs, Bugzilla, …— so you can safely ignore the [% %] and localize b[% %]ug but you would keep b[% %]ugs.debian.org unchanged.

Checking Templates

This step is important because if you have a wrong syntax in your template, this will break the user interface.

So, you need to get either the source tarball of the version you currently localize or to clone locally the Git repository matching your version.

To get the source with Git, run the following command:

git clone --branch bugzilla-X.X-stable https://git.mozilla.org/bugzilla/bugzilla

replacing "X.X" with the 2-digit version number of the stable release of Bugzilla that you want - e.g. "5.0".

To get the tarball, go on the releases page of bugzilla.org site, download the version you want and uncompress it on your computer.

Then, you can create a symbolic link towards your localized templates in the template/ directory or just copy your localized templates directory here:

    cd /your_bugzilla_directory/template
    ln -s /path_to_your_localized_templates/ab-CD ab-CD

Replace here ab-CD with your locale code.

You can see the checking scripts in the t/ subdirectory in your Bugzilla root directory.

To check the localized templates, you would only need to run these three ones:

t/004template.t
t/008filter.t
t/009bugwords.t

prove -Q t/004template.t

If your templates are valid, you should see a result like this:

t/004template.t .. ok         
All tests successful.
Files=1, Tests=1236,  5 wallclock secs ( 0.11 usr  0.00 sys +  4.70 cusr  0.05 csys =  4.86 CPU)
Result: PASS

If something went wrong, you will see something like this:

#   Failed test 'template/fr/default/index.html.tmpl has bad syntax --ERROR'
#   at t/004template.t line 106.
# Looks like you failed 1 test of 1236.

Test Summary Report
-------------------
t/004template.t (Wstat: 256 Tests: 1236 Failed: 1)
  Failed test:  671
  Non-zero exit status: 1
Files=1, Tests=1236,  4 wallclock secs ( 0.09 usr  0.01 sys +  4.74 cusr  0.04 csys =  4.88 CPU)
Result: FAIL

where you would hopefully see the faulty template and the line number where the error occurred.

Then, fix the error and run the scripts again.

Note: The following Perl modules are needed to run these scripts:

Math::Random::ISAAC
Email::Address
Email::MIME
Email::Sender::Simple
JSON::XS
File::Slurp
DateTime::TimeZone
DBI
Template

On Debian, run the following command to install them:

sudo apt-get install libmath-random-isaac-perl libemail-address-perl libemail-mime-perl libemail-sender-perl libjson-xs-perl libfile-slurp-perl libdatetime-timezone-perl libdbi-perl libtemplate-perl

Localizing The bzLifecycle.png File

This picture shows the lifecycle of a bug through its different statuses and resolutions. This picture is included in the documentation. It was generated using Dia.

To localize it, open the file docs/ab-CD/images/bzLifecycle.xml with Dia, localize it and export it as a .png file selecting the Pixbuf[png] (*.png) filter in the dropdown as docs/ab-CD/images/bzLifecycle.png.

Keeping Templates And Documentation Up-to-date

To keep your templates and documentation files up-to-date, you should watch the Bugzilla Git repositories to catch the changes in the aforementioned files.

Important: Besides these files, you should also watch the file filterexceptions.pl, which is located in the template/ab-CD/default directory. There is nothing to localize in it, but it should be kept up-to-date.

To do so, you might want to subscribe to the Atom or RSS feeds that log every commit in the repositories.

All the heads —understand the different versions of Bugzilla— can be found on the bottom of this page in the "heads" section. Click on the link of the version you want to watch. At the bottom right corner of the page that is then displayed, you will find the RSS or Atom link to subscribe to. An so, you will be noticed for each commit that happen on this head.

Note: the head named "master" is the future Bugzilla version which is in development.

Localizing The Documentation

The Bugzilla documentation uses reStructured Text (reST), as extended by our documentation compilation tool, Sphinx.

The Sphinx documentation gives a good introduction to reST and the Sphinx-specific extensions. Reading that one immediately-linked page should be enough to get started. Later, the inline markup section is worth a read.

As for the template files, the .rst files should be localized using an UTF8 compliant editor.

First copy the docs/en directory and rename it with your locale code. You can now start to localize the files.

Spacing, blank lines and indentation are very important in reStructured Text, so be sure to follow exactly the English pattern, otherwise, your localized version will not look the same as the English one and the layout might be very, very different.

Though I recommend you to read the documents stated above, here are a few rules:

• In index.rst files, never localize what is under the .. toctree:: directive: these are file names.
• Never localize a term surrounded with a double dot and two colons. For instance: .. warning:: This is a warning.. This will be automatically localized if necessary at compilation time. You can localize what is located after, in green in this example.
• Exception: do not localize what is located after the directive .. highlight:: console. The word console here is for formatting purpose.
• Do not localize a term surrounded with two colons or with the signs lesser than and greater than: :ref:`Démarrage rapide<quick-start>`. "ref" is a reserved word and "quick-start" is a file name. In the following syntax example, do not localize "using" as it is also a file name: :ref:`using`

Compiling The Documentation

To compile the documentation, you need to install the Sphinx software and at least the tool to convert .rst files into .pdf files:

sudo apt-get install python-sphinx rst2pdf

You can alternatively install TeX packages instead of rst2pdf, but they will take lots of space on your hard disk. If you still want to do so, run the following command:

sudo apt-get install python-sphinx texlive-latex-base texlive-latex-recommended texlive-latex-extra texlive-fonts-recommended

Note: PDF generation does not work currently with python3-sphinx package.

Another Perl module is needed by the docs/makedocs.plscript to launch the compilation:

File::Which

Run the following command to install it:

sudo apt-get install libfile-which-perl

Now, you can test that your installation is functional by running the following command in the docs/directory:

./makedocs.pl

This will generate the English documentation files in HTML, PDF and plain text formats in the docs/en directory and its subdirectories.

If all is running fine, you can then copy your localized directory in the docs/ directory. You should have then three directories:

|-- docs
|    |-- ab-CD
|    |-- en
|    |-- lib

Where ab-CD is your locale code.

You should now customized the file docs/ab-CD/rst/conf.py. Here are the section you should take care of:

# General information about the project.
project = u'Bugzilla'
copyright = u'2014, The Bugzilla Team'

latex_documents = [
  ('index', 'Bugzilla.tex', u'Bugzilla Documentation',
   u'The Bugzilla Team', 'manual'),
]

man_pages = [
    ('index', 'bugzilla', u'Bugzilla Documentation',
     [u'The Bugzilla Team'], 1)
]

texinfo_documents = [
  ('index', 'Bugzilla', u'Bugzilla Documentation',
   u'The Bugzilla Team', 'Bugzilla', 'One line description of project.',
   'Miscellaneous'),
]

pdf_documents = [
('index', u'Bugzilla', u'Bugzilla Documentation', u'The Bugzilla Team'),
]

You can localize what is hightlighted above in green.

rst_epilog = u"""

----------

This documentation undoubtedly has bugs; if you find some, please file
them `here <https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation>`_.
"""

For this section, pay attention to the letter u added before the three double quotes: it is not present in the English version of this file. This letter indicates that the text following will contain non-ASCII characters and your language certainly needs non-ASCII characters. If you omit to add this letter and that your localization contains non-ASCII characters, the compilation of the documentation will not work. The multiple dashes are here for formatting purpose and will render as a line in the HTML version.

Another section you would want to edit is the following one:

# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None

You should uncomment the line and specify your locale code here:

# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
language = 'fr'

For a list of available locales, you can consult Sphinx documentation.

If your locale is not present, then the different labels for navigation —next, previous, search box, etc.— will not be localized. If this is the case, let this line commented; these words will be then displayed in English.

Hosting The Documentation On ReadTheDocs.org

First, you need to have a DVCS repository of your files accessible from Internet. ReadTheDocs.org supports currently Mercurial, Git, Subversion and Bazaar repositories. You can create your repository on sites such as Sourceforge.net.

When creating your branches in your repository, you should follow the Bugzilla project naming rules that is:

• Either name your branches or heads with the major number of the release, for instance 5.0
• Or tag your set of files with the major number of the release each time you modify your files and want to get it recompiled by RTD.org site

As an example, I already had a Mercurial repository to manage Bugzilla localization for the four supported branches and I used branch names like BUGZILLA_4_4 or BUGZILLA_5_0. So, each time I modify my localized files and I want them to be recompiled, I force the tag on my branch:

hg tag -f 5.0

ReadTheDocs.org site will get all the branch and tag names in your repository so you will only have to pick the right one in its interface.

Also, unless you host in your localized repository the Bugzilla source code, you will need to do the following: adding the file Constants.pm which is located in Bugzilla root directory and modifying your conf.py file:

|-- docs
|    |-- ab-CD
|       `--Constants.pm
|-- extensions
|-- template

I added it in the docs/ab-CD/ directory, but you can add it elsewhere. I would recommend you not to put it at the root of your localized files —that is to say at the same level as the docs/, extensions and template directories. If the user installs an old version of your localized tarball or if you forget to update this file, this will break Bugzilla by replacing the Constants.pm file provided by the Bugzilla source tarball. Then, the docs\ab-CD\rst\conf.py needs to be modified to reflect this change in the following section:

for line in open("../Constants.pm"):
    match = re.search(r'BUGZILLA_VERSION\s+=>\s+"([^"]+)"', line)
    if (match):
        release = match.group(1)
        match = re.search(r'^\d+\.\d+', release)
        if (match):
            version = match.group(0)
        else:
            version = release
        break

You will need to keep Constants.pm file in sync with the English version for each branch or head.

Then, get on ReadTheDocs.org site and create your account by clicking on the button Sign up. Fill up the form and click on the Sign Up » button:

On the page that appears, click on the Import a Project button:

Then, either connect to your GitHub or Bitbucket account or click on the Manually Import Projectbutton —below will be detailed the manual way as I have not any account on GitHub or Bitbucket.

You should now name your project, following the naming rule bugzilla-ab-CD —where ab-CD is your locale code—, specify the URL for your repository and its type, and tick the Edit advanced project options: square. Click then on the Next button:

Fill now the new form, especially the Description, Documentation and Language fields. The other fields can be ignored and modified later if necessary. Then, click on the Finish button:

Now, click on the Versions button in the navigation header and in the Inactive Versions section, choose the version you want to activate by clicking on the Edit button:

Tick the Active: square and click on the Save button:

Now, click on the Overview button in the navigation header. The version you have just made active should appear there. In the Build a version dropdown list, select the version you want to compile abd click on the Build button to compile your localized documentation:

If the result is Passed, your documentation has been successfully compiled. If the result is Failed, click on the link to see what went wrong and fix it.

Finally, you should inform the Bugzilla Project that the documentation is ready in your language by sending a mail to the mailing-list developers AT bugzilla.org giving your project name, that is bugzilla-ab-CD.