Handling Translation Issues

From Apache OpenOffice Wiki
Jump to: navigation, search

This page provides information about handling translation issues for languages where Sun is involved in the translation. At the moment, this applies to the following languages:

  • French (FR)
  • Italian (IT)
  • German (DE)
  • Spanish (ES)
  • Brazilian Portuguese (PTBR)
  • Swedish (SV)
  • Dutch (NL)
  • Polish (PL)
  • Russian (RU)
  • Hungarian (HU)
  • Portuguese (PT)

How to submit a translation issue

A correctly submitted translation issue should:

  • have Component set to l10n
  • be assigned directly to the person responsible for fixing translation issues for the languages listed above - currently petr_dudacek
  • have the language code specified in square brackets in the beginning of the Summary field, for example: [IT] missing translations in File -> Open dialog

Additional information that is useful for locating the strings that need to be fixed:

providing information about both UI and OLH
when submitting a UI (User Interface) issue, it is always good to add information about the needed fixes in the OLH (Online Help). This means not only saying this needs to be fixed in the Online Help as well but try to find the corresponding Help page(s) and add information about how to get to that page(s).
each string is identified by its KeyID, which is a unique 6-digits identifier that helps to quickly locate the string in the Sun's translation database. The KeyID can be obtained from a so called KeyID build. Providing the KeyIDs of strings that need to be fixed makes it very easy for the responsible engineer (owner of the issue) to find the string in the translation database.
steps to locate the string(s)
when a KeyID build is not available, it is enough to provide the exact steps to locate the string, for example:
  1. open Writer
  2. go to Format -> Character...
  3. select the Hyperlink tab
  4. click the Events button to open the Assign Macro dialog
  5. the Remove button text is not translated.
suggested fix
if possible, it is always useful to suggest a fix: most often, this means to suggest how the string should be translated or how the current translation should be changed. When suggesting a translation change, it is good to provide
  • the current (wrong) translation
  • the new (corrected) translation
This helps the responsible engineer to see the difference.

When there are more strings to be fixed, it is not necessary to provide the steps to locate each of them - this would be too time consuming. In that case, the workflow described in the next section will be used.

Handling complex translation issues

When there are more strings that need to be fixed in the same way (for example when the translation of a certain term needs to be changed across the whole office suite), the issue lifecycle will be the following:

  1. issue submitted
    Component, issue owner and Summary is set in the same way as described above. The issue is in UNCONFIRMED or NEW state.
  2. issue confirmed and evaluated
    The responsible engineer confirms that this is a valid issue. Then, he appends an sdf file containing the strings that need to be corrected. The issue is set as STARTED.
  3. strings corrected
    The Community will then correct the strings and add useful information in the issue that may help during the linguistic approval process. The sdf file containing corrected strings will then be attached back to the issue.
  4. corrections approved
    The approval will be made by the TPM (Translation Project Manager) or LL (Language Lead).
  5. corrections imported
    The corrected sdf file will then be imported into the translation database. The issue is set as FIXED.
  6. corrections verified
    Either the Community or the responsible engineer (or both), will verify the corrections in a CWS build. The issue is set as VERIFIED.
  7. corrections verified in a master build
    Once the corrected strings are verified in a master build, the issue is set as CLOSED.
Personal tools