NLC:ReleaseChecklist

How to get OpenOffice.org released in my language

Do you want to translate OpenOffice.org for your language community, and release it officially with other OpenOffice.org builds? Great! :D

When you first start at OpenOffice.org, everything is new, and the procedures may be different from other projects you've experienced. However, just like in other projects, you organize your workflow and go through the tasks one by one. This document summarizes the steps you need to complete to release an official OpenOffice.org version in your language.

It describes each step, and also includes a summary list at the bottom of the page. You can save a copy of this page, and [√] tick off the steps as you go.

Create your project

Each language team is called a Native Language Project, and all language projects are members of the Native Language Confederation.

If there is not already a project for your language, you need to create one. Follow the guidelines on the NLC wiki page, to create your project. Basically, you need to join the dev@native-lang.openoffice.org mailing list. [ ]

Then send the project proposal email to that list. [ ]

Once your project proposal has been accepted, send the follow-up information to that list. [ ]

In any case, while you're waiting for other things to happen, you can go on setting up your OpenOffice.org access.

Become a member of OpenOffice.org

Sign the SCA

In order to contribute any material to OpenOffice.org, you need to sign the Sun Contributor Agreement for this project.

Simply download the form, fill it out, sign it and post it (or scan and email it) to the contact details on the form. [ ]

Once your name is posted on the Copyright Approved List, your SCA has officially been submitted and accepted. [ ]

Register with the OpenOffice.org website

The OpenOffice.org website offers you a number of important services, including a site for your language team (e.g. fr.openoffice.org for the French team), so it's important that you register with our website.

Go to the Contributing sub-project site and use the Register link in the top right-hand corner, or simply click on this Join link. Fill in your username and email address, and click on the Register button.

You will receive an email which tells you how to login to our site. Once you can login to openoffice.org, you have a working OpenOffice.org registration. [ ]

Where do I fit in?

It is also useful to understand the overall structure of the OpenOffice.org project, which is shown by the website. OpenOffice.org is a very large and complex project composed of a number of sub-projects. Think of it as a busy parent with a lot of children!

Your translation project will be one of those children or sub-projects. All the other language teams are also sub-projects. So are aspects of OpenOffice.org like Marketing, Website, Security and QA, as well as ports of OpenOffice.org to specific architectures.

The key thing to remember is that each project has its own sub-domain on the website, and you can find that location simply by inserting the sub-project name before the main domain name (openoffice.org). So the French project is at fr.openoffice.org, the Website project is at website.openoffice.org and the porting project is at porting.openoffice.org.

Each sub-project has its own webpages, mailing lists and tasks. But we all work together. :)

Access the tools

OpenOffice.org provides a number of useful tools to aid your localization project. You need to gain access to them, and learn how to use them.

Source control

Your website files on OpenOffice.org, and your translation files if you choose, will be stored in the OpenOffice.org CVS repository. CVS is not difficult to use, and we are happy to help you with setting up your access. You need a SSH key to access OpenOffice.org CVS.

Submit your SSH key

A SSH key is a way of identifying you to the OpenOffice.org CVS server. Each time you connect to the server, the key you send in here will be compared with the key on your own computer. This means you don't have to input special login information: once you get it set up, it's a very convenient way to manage logins. You will be able to use the same key pair to login to different projects, whether they use CVS or SVN.

Create your SSH key pair. To do this, please see the SSH with Keys HowTo; you can also use the GUI utilities Putty for Windows and SSHAgent and SSHKeychain for Mac OSX.

In summary, to create a SSH key pair, in a terminal window use the command "ssh-keygen", then input the location to save the keys, then input the passphrase (a fairly long and complex password) for the keys. Make sure you record your passphrase!

Your SSH key pair has been created. [ ]

The SSH key pair is composed of the public key and the private key. The private key you keep on your computer, but the public key you send in to servers where you want SSH access.

Your public key will have a filename ending in ".pub", e.g. "id_rsa.pub". At some projects, you will be asked to email your key to the admins, but in a project as large and complex as OpenOffice.org, all data is submitted via the Issue Tracker. The Issue Tracker processes not only bugs, but also feature requests and data submissions. You will submit your translations via the Issue Tracker, so it's important to learn how to it. The Issue Tracker link is in the left-hand sidebar of each project page.

To submit an issue to the issue tracker, first you click New (or Task in this case), then choose a Component (in this case, "www"), a Subcomponent (OpenOffice.org website general issues), Version (current), and Assign to (ssh2key).

Then you attach your key file to the issue. With Issue Tracker, you have to submit the issue first, then attach a file. So hit Submit, then click on the link to attach a file to the issue. Click the button to choose the file on your disk. Choose its filetype from the drop-down menu (it's just a text file), then describe it, e.g. "SSH key for CVS access". Submit the changes.

Your SSH key has now been submitted. [ ]

Write to the dev@native-lang.openoffice.org mailing list, saying you have submitted your SSH key, and ask for support in resolving that issue. [ ]

Tunnel into OpenOffice.org

Once your SSH key has been accepted, you need to setup your SSH tunnel, and access the OpenOffice.org CVS repository, to create/modify your webpages. Your directory should have a default set of webpages you can use and enhance. Please refer to the instructions for accessing OpenOffice.org CVS. If you have any problems, please ask for help on the dev@native-lang.openoffice.org mailing list.

SSH tunnel to OpenOffice.org has been setup. [ ]

Access webpages in CVS

You can browse your current CVS repository from the Version Control link in the left-hand sidebar of your project site. Check out your working copy.

OpenOffice.org CVS has been accessed successfully via the SSH tunnel. [ ]

Create project webpages

You and your team will want to create some webpages unique to your language and culture, introducing your project, explaining its goals, and informing your community about OpenOffice.org and your upcoming translation. This won't all happen at once, but it's important at this stage, at least, to have some basic data on the homepage.

The project homepage has a summary of project status. [ ]

It is important that your project webpages are created and kept up-to-date. Your project website is the first point of contact for your language community.

Issue Tracker

You have already submitted one issue via the Issue Tracker, but you will need to use it often, to submit and manage bugs, submit and track translations, and authorize and track releases.

Please read the documents about issues and how to report them.

The Issue Tracker instructions have been read. [ ]

Note that you must be logged in to use the Issue Tracker. Keep an eye on that login field in the top right-hand corner of the OpenOffice.org website pages.

If you have any problems at all, including when reading the documentation or using Issue Tracker, please ask for help on the dev@native-lang.openoffice.org mailing list.

Mailing lists

As we said before, each sub-project in OpenOffice.org has its own mailing lists. There are so many of them! You can read different ones (e.g. via Gmane for different purposes.

However, as a team leader, you do need to subscribe to some key mailing lists. In addition to dev@native-lang.openoffice.org, which you have joined earlier in these instructions, you need to join dev@l10n.openoffice.org (the l10n project specializes in translation issues), and join both the announce@ and releases@ lists. See their descriptions on the central Mailing Lists page.

Subscribed to:

• dev@l10n [ ]
• announces@ [ ]
• releases@ [ ]

You should also setup your own project's mailing lists (use the Mailing Lists link in the left-hand sidebar on your project website), and use them to discuss your own project issues in your own language.

Project mailing lists are setup and being used by project members. [ ]

Translation tools

Each translator can use his or her favourite editor to work on OpenOffice.org files. See the main L10N page, especially the Translation details page.

OpenOffice.org is a very large corpus of translation strings, so you will need a lot of people-power to get the translation completed, and maintain it.

OpenOffice.org translation files are available in PO format, so you can use your favourite PO editor. To distribute the enormous task of translating OpenOffice.org, and make it much easier for your translators to participate, you can also use our Pootle. For more information on the free-software distributed translation tool Pootle, please see its wiki pages.

To use our Pootle, you will need to request your language be added to it, on the dev@i10n.openoffice.org mailing list. Then you need to register, and request to be added as the admin for your team. Then your translators need to register, so you can assign access rights and goals to them in the way that suits your project best. Translators on probation, for example, can be assigned only right to "Suggest", so their input is saved separately as draft translation strings for you to review.

• Language added to Pootle [ ]
• Team leader registered [ ]
• Team leader added as admin [ ]
• Translators registered [ ]
• Translators assigned [ ]

You can run Pootle offline (e.g. for translate-a-thons), online or both, and translators can choose to use it always, some of the time or not at all. You can download whole directories or separate files in a range of formats from Pootle, and you can upload edited files, to overwrite or merge with the current online file. Get to know Pootle, because it will save you a lot of work in the long run.

Again, please ask questions about Pootle, and translation matters in general, on the dev@i10n.openoffice.org mailing list.

You need to read our translation documentation carefully, so you know how to translate the different kinds of strings, and how to check your translation so it won't break the OpenOffice.org build when it is reintegrated.

Checking tools

You must check your translation with gsicheck. When the translation is in PO file format, you can also use pofilter, e.g.

pofilter -t accelerators -t escapes -t variables -t xmltags --openoffice PO_DIR OUTPUT_ERROR_DIR

gsicheck downloaded and installed [ ]

pofilter downloaded and installed [ ]

QA tools

We have some excellent tools to help you test your translation and track that testing. You will be using them later on in the process, but you need to register with them first.

QATrack allows you to keep track of the testing of each build (e.g. Linux, Windows, OSX) for your language. Please read the QATrack wiki doc., and register with qatrack itself by asking the dev@qa.openoffice.org mailing list. Request the builds you want shown on qatrack, or submit them yourself.

• Registered with qatrack. [ ]
• All builds requested. [ ]

TCM helps you work through the various tests needed to check that your localized builds work properly and thus can be released officially. Please read the TCM wiki doc. and register with TCM itself. Assign your testers to different builds. Make sure they have also registered with TCM.

• Registered with TCM. [ ]
• Testers for different builds assigned [ ]
• TCM doc. translated to help testers [ ]

testtool is an application and set of scripts used to run automated tests on OpenOffice.org builds. This can save you a lot of time. You can read the testtool sample instructions for Fedora Core 6 and Windows XP. For further information, ask on the dev@qa.openoffice.org mailing list.

• Downloaded and installed testtool. [ ]
• Read/translated instructions for the translated builds [ ]

Planning tools

All the tools you've setup above will help you during the release process. In order to plan your release, you also need to keep track of the Release Schedule, e.g. for version 2.2.

This release schedule will be posted on the dev@i10n.openoffice.org mailing list.

Bookmarked the release schedule [ ]

You can see a slideshow about the OpenOffice.org release process. Note that after OpenOffice.org 2.2, the release interval will be six months. This allows more time for Quality Assurance (QA).

You can also use project-planning software and calendar software, as well as the Pootle goal-assigning features, to keep track of who needs to do what in time for release.

But the most important tool in your OpenOffice.org toolkit is communication. Ask questions on the mailing lists. Track down answers. Create documentation. Ask other translators to share their experiences. Ask for help.

And in turn, as project lead, encourage your translators to do all these things within your project. :) Promote discussion on your lists, and act as the communication link between the larger OpenOffice.org project and your own project. Keep your project members informed, and encourage them to ask for help.

You can keep track of translation statistics (always available and current in Pootle), and post them to your project mailing lists. Encourage your project members and community to contribute artwork, documentation, bug reports and FAQ items. Everyone has something useful to contribute.

Translation goals

The OpenOffice.org translation corpus is composed of several different parts, some less obvious than others. It's important to have a comprehensive list of all the material you need to translate. Again, see the Translation page.

The OpenOffice.org interface strings comprise about 120 000 words. In the PO hierarchy, the interface is represented by all the directories except helpcontent2. helpcontent2, also referred to as "the Help", or "Help", or "online Help", comprises over 400 000 words.

Your first priority should be the interface strings, then you can work on the Help over time. First priority in the Help should probably go to the tooltips which appear when you hover the mouse over a menu item, icon, window title etc. in an OpenOffice.org application. Then you can work on the explanations in the Help window itself.

Additional translation strings are found in the Autotext, Samples, Templates, and the testtool scripts. Especially when creating a project, you also need to work on the locale data used by OpenOffice.org.

Project locale is correct. [ ]

And, of course, there is a great deal of very helpful OpenOffice.org documentation currently available in English, or other languages, which can be translated into your language. This is a useful task for translators who specialize in one or more of the OpenOffice.org components. For example, if one of your translators knows a lot about using Calc, suggest s/he translate some of the Calc help docs. These docs can then be hosted on your project site (Documents and Files), for your community members to download.

For your first release, you need to translate at least 80% of the interface strings.

>80% of the interface strings have been translated. [ ]

Submit your translation

Before the translation deadline for this release, you need to submit your translation. So start checking your translation a few days before the submit date. It's a big file and may have some problems that have to be resolved.

Translation file has been checked. [ ]

If there are any problems you can't solve directly, please ask on the dev@i10n.openoffice.org mailing list.

To be submitted, the translation has to be in .sdf format, and must be uploaded to an FTP or HTTP site, the link to which you will include in your translation-submission issue.

Please see this howto for details on converting PO files to sdf format, and checking your file.

Translation file has been uploaded in .sdf format. [ ]

Download link works. [ ]

To submit your checked .sdf file, go to Issue Tracker and choose:

• New issue
• Component l10n
• Sub-component code
• Issue type ENHANCEMENT
• The version for which you are submitting your translation.

The summary line should describe the type of strings, language and version. For example:

• [VI] GUI Translation for 2.2 — to submit all the directories except helpcontent2 for Vietnamese
• [PT_BR] Help translation for 2.2 —to submit only helpcontent2 for Brazilian Portuguese
• [ZU] GUI and Help Translation for 2.2 — to submit all the directories for Zulu
.

The only things which vary about the issue are the version number and the person to whom the issue is assigned. All the issue details will be posted on the dev@i10n.openoffice.org mailing list. So keep an eye out for them, and note them down when they appear.

Include the link to your uploaded translation.

You can also briefly describe your translation, e.g. "Here is the initial Xhosa translation for the OpenOffice.org 2.3 GUI (100%)." or "Here is the updated Catalan translation for OpenOffice.org 2.4. We have translated all of the GUI and 60% of the Help."

Submit the issue.

Translation-contribution issue has been submitted. [ ]

Test your localized builds

Once your issue is submitted (even earlier, if you arrange it with Pavel Janik), your translation will be included in the next build. You can download it from the build server (e.g. ftp.linux.cz and start testing it.

In order to test it, you use TCM and testtool to run through the required tests, and qatrack to keep track of and record progress in testing.

Only the release-sanity scenario in TCM (including the testtool automated tests) is compulsory for a release, but of course, the more testing you can do, the higher the probability that your builds don't have many remaining bugs. Translate the test cases in TCM, and encourage not only your team-members, but other members of your community to run these tests. You can also create questionnaires out of the scenarios, which community members can download and fill in. This all brings you in more QA data.

Release-sanity scenario completed for:

• Linux [ ]
• Windows [ ]
• Mac OSX [ ]
• Solaris [ ]

Once the release-sanity scenario has been completed for any build, without any significant bugs being found, you can release that build. You don't have to wait until all your builds have passed QA: you can release them separately.

To authorize release for one or several builds, first modify your qatrack record to show "approved" for each build you are about to release,

qatrack shows "approved" for builds to release [ ]

then file an issue (e.g. like this).

• New issue
• Component qa
• Sub-component www
• Issue type ENHANCEMENT
• The version for which you are releasing your translation.

Include the link to each build to be released, and state that each one has passed QA, and that you authorize its release. Request Bouncer links if you want them.

Submit the issue.

Release authorization issue submitted. [ ]

When that issue is resolved by the admin, check the download links s/he lists in the issue.

Download links work. [ ]

Announce the release to your language community. (For help with promotion materials, see the Marketing project.)

Release announced. [ ]

Congratulations on your first official OpenOffice.org release! :D

And the whole cycle starts again... but after the first time, you are all set up for the process, you understand a lot more about how things work, and it should be much easier.

Summary of the steps to your first OpenOffice.org release

1. Create your project [ ]
   1. Join the dev@native-lang.openoffice.org mailing list [ ]
   2. Proposal email [ ]
   3. Follow-up information email [ ]
2. Become a member of OpenOffice.org [ ]
   1. Sign the SCA [ ]
      1. Sign and send in the SCA [ ]
      2. SCA has been approved and listed [ ]
3. Register with the OpenOffice.org website [ ]
4. Setup tools
   1. Submit your SSH key [ ]
      1. Create the key pair [ ]
      2. Submit the SSH key issue [ ]
      3. Post to the dev@native-lang.openoffice.org mailing list about approving your SSH key issue [ ]
   2. Setup SSH tunnel to OpenOffice.org [ ]
   3. Access your CVS repository [ ]
   4. Create basic project webpages [ ]
   5. Read Issue Tracker instructions [ ]
   6. [Subscribe to announce@ and releases@ mailing lists [ ]
   7. Setup and use your project's mailing lists [ ]
   8. Pootle setup [ ]
      1. Language added to Pootle [ ]
      2. Team leader registered [ ]
      3. Team leader added as admin [ ]
      4. Translators registered [ ]
      5. Translators assigned [ ]
   9. Checking tools setup [ ]
      1. gsicheck downloaded and installed [ ]
      2. pofilter downloaded and installed [ ]
   10. QA tools setup [ ]
       1. qatrack
          1. Registered with qatrack. [ ]
          2. All builds requested. [ ]
       2. TCM setup [ ]
          1. Registered with TCM. [ ]
          2. Testers for different builds assigned [ ]
          3. TCM doc. translated to help testers [ ]
       3. testtool setup [ ]
          1. Downloaded and installed testtool. [ ]
          2. Read/translated instructions for the translated builds [ ]
   11. Release tools setup [ ]
       1. Bookmark the release schedule [ ]
5. Translation complete [ ]
   1. Project locale is correct [ ]
   2. >80% of the interface strings have been translated. [ ]
6. Submit translation [ ]
   1. Translation file has been checked. [ ]
   2. Translation file has been uploaded in .sdf format. [ ]
   3. Download link works. [ ]
   4. Translation-contribution issue has been submitted. [ ]
7. QA for translation is complete [ ]
   1. Release sanity scenario is complete for:
      1. Linux [ ]
      2. Windows [ ]
      3. Mac OSX [ ]
      4. Solaris [ ]
8. Release translation [ ]
   1. qatrack shows "approved" for builds to release [ ]
   2. Release authorization issue submitted. [ ]
   3. Download links work. [ ]
   4. Release announced. [ ]