openSUSE:Localization guide

Jump to: navigation, search

In this page find information about localization (L10N, LCN) of software components in openSUSE. It applies for programs such as YaST, the openSUSE update applets, or the menu system of the desktop. For information about localizing the openSUSE wiki (this site), see Help:Translation.

openSUSE Weblate

All translators should join openSUSE Weblate translation portal. All openSUSE translations are done there.

To work with openSUSE Weblate, you don't need any programming skills. You even don't need to know translation files formats. You just need a good knowledge of the selected language, and the established computer terminology.

openSUSE/SUSE specific translation projects

Besides generic translation projects for in-house projects (like YaST) and hosted projects, there are translation projects for specific purposes that handle translations for openSUSE/SUSE only.

update-desktop-files and desktop-file-translations

Started in 2003 to fulfill a Novell Linux Desktop 9 goal of 100% translation of the desktop menu. The implementation uses SUSE-first (in the past SUSE-only) policy, so it contradicts with the current upstream first policy. It also supports application categories remapping and fixing obsolete formats of desktop files. To import the translations back, a patch in glib2 and KDE exists, and YaST contains a dedicated code.

The original implementation uses %suse_update_desktop_file macro in the spec file, %install stage.

Since 2011 the implementation does not depend on the macro. It uses a brp script that originally removed all upstream translations (now it keeps them). As the package is a part of several {meta}-devel-packages, the script is automatically deployed to all packages using one of these meta packages in BuildRequires.

A custom toolchain running on the OpenQA intranet VPN collects all desktop files in a selected projects and puts it to GitHub and connected Weblate project.

In 2024, the project got a code that allows to upstream the changes, and the project itself was marked as deprecated.

packages-i18n and package-translations

This project allows to translate rpm summaries and descriptions in the YaST installer. The toolchain downloads all packages in selected projects and sends it to the translation project. Over the time, the number of packages in the distribution significantly raised, so it generated an extremely large translation project. It results in a low translation coverage.

gnome-patch-translations

In 2004, Novell released a Novell Linux Desktop 9 based on a heavily patched GNOME 2. Many strings in the patches were not translated, resulting in an inferior i18n experience. That is why this project was created. It was based on dedicated commands used in the %prep stage of spec files. The toolchain ran the package setup, compared the source strings before and after patching and generated a translation project that merged such strings from more packages. Later, openSUSE moved to the original upstream packages, and the project lost its importance. The project existed in openSUSE LCN SVN, and it was never migrated to GitHub nor Weblate.

  • Year of introduction: 2006
  • End of active maintenance: 2016
  • Removal process started: 2021
  • Number of packages involved: ~ 20
  • Number of strings to translate: ~ 120
  • Package name: gnome-patch-translation
  • SVN project: https://svn.opensuse.org/svn/opensuse-i18n/{branch}/lcn (decomissioned)
  • Weblate translation project: N/A

translation-update

A translation update bundle that allowed release of online update for any package, overwriting translations distributed with the package rpm files. It used a dedicated directory and a glibc patch that forced that directory over the standard locale directories. In 2013, it got an update that allowed to semi-automatically import upstream translations.

The downstream translation project existed in openSUSE LCN SVN, and it was never migrated to GitHub and Weblate. The upstream import project was completely handled by supplementary scripts, and it had no translation interface.

If the update file was present, patched glibc forced it and completely ignored translations distributed with the package. (The implementation was a bit inferior, as recent glibc versions already support translation search path with mixing of multiple files.) If the update was not in sync, it caused a regression. That is why it was deprecated and translation archives removed in the last years of its existence.

  • Year of introduction: 2006
  • Deprecated: 2019
  • Dropped: 2024
  • Number of packages involved: ~ 100 (translated by downstream, possibly duplicating the upstream), ~250 (translated by upstream)
  • Number of strings affected: ~ 20000 (provided by downstream, possibly duplicating the upstream), ~ 50000 (provided by upstream)
  • Package name: translation-update
  • SVN project: https://svn.opensuse.org/svn/opensuse-i18n/{branch}/lcn (downstream part; decomissioned)
  • Weblate translation project: N/A

translation-update-upstream

In the past, GNOME was frozen in an early stage of product development. In that time, the upstream translation was often incomplete, and the better support appeared in the later versions.

This package that allowed to semi-automatically import upstream translations and provide them separately without touching the code, even after the release. It supported import to the spec files before the release using a dedicated command in the %prep phase of the rpm spec file, triggering each included package rebuild, and import them to translation-update for packages that will not get a rebuild using this macro (e. g. after the release). The toolchain unpacked sources in a controlled environment, applied patches, generated pot files and backported the latest upstream translations from the selected VCS branches or selected sources.

Due to nature of the toolchain, the full run took about one day and it was sensitive to failures. And it also triggered hundreds of packages to rebuild.

In the later years, the GNOME update model changed. Version updates were done even in the late development. It brought the new upstream translation directly to the package. It decreased the importance of the package. And it also caused problems with keeping it in sync. Each single package version update outdated the translation-update-upstream, and also translation-update packages. As translation-update translations were forced over the upstream ones, it started to cause translation regressions.

  • Year of introduction: 2009
  • Deprecated since: 2019 (now does nothing)
  • Number of packages involved: ~ 250 (translated by upstream)
  • Number of strings affected: ~ 73000 (provided by upstream)
  • Package name: translation-update-upstream
  • GitHub project: N/A
  • Weblate translation project: N/A

translate-suse-desktop

There are desktop files completely created and maintained by openSUSE or SUSE package maintainers that need translation. As the previous project update-desktop-files does not discriminate between such projects and packages that has a desktop file that comes from the upstream, a new project was created. It is a minimalistic tool using intltool to integrate translations and OBS getbinaries feature to collect translations from more packages. A migration tool inside the toolchain allows automatic migration of existing update-desktop-files translations after the migration of the spec file.

locale langpacks and bundles

Locale langpacks were not translation projects per itself. These projects just took lang sub-packages from existing packages, and repackaged it. The toolchain took packages in the original -lang layout = all translations for a single package, and it created a package for a single language containing translation files for many packages (e. g. all GNOME packages). Using rpm requires/provides and language settings, these packages were installed instead of the -lang packages. That repackaging saved the installation size of a monolingual desktop.

To prevent file conflicts, it used dedicated directories /usr/share/locale-bundle and /usr/share/locale-langpack. A patch in glibc took absolute preference to files in these directories. In case of a single package version upgrade, it caused translation regression (stay at old version).

  • Number of packages involved: ~ 500
  • Year of introduction: 2006
  • Active use stopped: 2018
  • Support removed: 2024

Joining an Existing Team

All translators are encouraged to join opensuse-translation mailing list and eventually language team lists.

If a language team exists for your language, contact coordinator of the team.

Adding a new language

There is no technical limit for the translation. Most projects allow you to start new translations by a single click. But getting a good native language experience requires a lot of work. So it is recommended to have a translation team.

If your language is already included in the Localization team list, a team for your language exists. Find Information about joining a team in Joining a Existing Team. If there is no team for your language, start one and proceed as follows:

  1. Mail to opensuse-translation@opensuse.org. Within your mail, provide the following information: new language name, your full name, your contact mail address.
  2. Wait for approval of the new language project.
  3. Add your language to the table of localization teams. Also fill out the fields about the language coordinator and the location of your project pages, see Language Project Page.
  4. Start with localization. Read Starting Work before you begin.

Translation with Weblate

You can get a good overview about all translation projects, their status and translation files with openSUSE Weblate. Use your general openSUSE account there. Anybody could create it.

Language teams can limit access as agreed by the team policy.

You should change only files of your language team.

The translations are split to projects and components. Components can be branches or subdomains of the project, or their combination.

Branches

Packages can have different branches, which is reflected as different components in Weblate. A branch is a directory with a specific version of files. So you can find different translation files for the same software. Most of the projects has a master or main branch intended for Tumbleweed, and projects can have specific branches for Leap and SLE. You needn't translate components with SLE in the name. Such files are translated by SUSE for SUSE Linux Enterprise. We share our systems with them.

Many projects don'have these dedicated branches, and the translation development is common for both Tumbleweed and the next Leap.

After that you can select your language.

However there is available a PO download button, and local offline translation is still supported, translators are encouraged to translate online in Weblate.

Simply choose "Not translated string" and you can enter your translations in the web interface.

The Most Important projects

If you are at the beginning of localization, you should start with the most important files. These files belong to the most visible applications of the openSUSE distribution, like installation or YaST Control Center. The most important files are:

For installation: * download.o.o

  • software-o-o
  • landing-page
  • openSUSE-EULAs
  • release-notes
  • skelcd-openSUSE
  • yast-slide-show
  • packages-i18n/patterns

Software installation and rollback: * libzypp

  • snapper
  • zypper

YaST basics: * yast-base

  • yast-country
  • yast-firewall
  • yast-installation
  • yast-ncurses
  • yast-ncurses-pkg
  • yast-network
  • yast-pam
  • yast-pkg-bindings
  • yast-qt
  • yast-qt-pkg
  • yast-storage
  • yast-timezone_db
  • packages-i18n/yast2

SUSE translations

We are sharing Weblate with SUSE Linux Enterprise Translators. There are many po files for YaST, you don't have to translate. They are marked with comments as:

This is a SUSE Linux Enterprise module, not intended for community usage.

or something equal to that:

RPM repository mirroring tool and registration proxy for SUSE Customer Center is an SUSE Linux Enterprise product. It is translated by contracted translators.

In deep information

openSUSE Weblate is just an interface to the openSUSE GitHub project and YaST GitHub development portals. It holds copies of these projects and returns all translation work back to the development git repositories.

About PO and POT Files

Most (but not all) projects use bilingual po files. Source contains English text, and the translator provides a translation.

Original English text in the PO file is not allowed to change. You can change only translation. If you find an error in the original English text, please use Bugzilla to report it. All wrong texts must be fixed in the source code of the application first and then a new POT file will be generated and automatically merged with your files. After it, the changed string will be marked as fuzzy (i. e. Needs edit).

If you do not know, what is the PO and POT file, please read article Work with PO Files.

Not all projects use po or even bilingual files. But, thanks to Weblate, this fact is nearly opaque to the translators. The presence of editable English translation is the only difference of components that user monolingual files.

Pull Requests on GitHub

Most Weblate projects are configured to an automatic push of translations back to GitHub. The synchronization time is set to 2 hours after last edit.

All po files are available on github and will be updated by Weblate and Developers.

If you want to commit po files on GitHub, you have to create a fork, clone it, commit, push and create a Pull Request. Do it only if you aren't able to upload po files for "Most important files" with Weblate and we have got release time. The reason is that a Pull Request must be reviewed by the project owner. That can use time and many commits can be executed then. So there can occur a merge conflict.

You can find the special link to the github repository on Weblate, if you choose your translation file, click on the name above and choose "Information". The Project website is the github repository.

Minimal Translation

We have no percentual limits for including localization to distribution.

Statistics

Information about state of your localization work you find in statistics of Weblate. If your language is not included, please send an email to the opensuse-translation mailing list.

Statistics are updated once a day. Time of the update is displayed at the bottom of each page. If there is any missing translation of some file in your language, the file is displayed as untranslated and linked to the POT file. You can translate the POT file and commit to github/ Weblate as the PO file or wait for initialization of the POT file.

Language Team Pages

If you work in the large team, you should have your own team page in your native language. To create one, use openSUSE wiki in your language and add the link to the table of localization teams. If there is no openSUSE wiki translated into your language, create team page in the English wiki page with name your_language_code Language_name Localization Team.

Tools for the old style offline work

Weblate is preferred for an online work. But you can still translate offline using one of offline po editors.

  • POEditor - POEditor is a web-based translation tool for gettext po files and other popular localization formats
  • KBabel - KBabel is the part of the package kdesdk3-translate
  • Lokalize - Lokalize is KDE4 successor of KBabel

Handling translation bugs

If you find a translation bug (untranslated string, incorrectly translated string, untranslatable string), please follow Handling translation bugs manual.

Links


How to Participate
Participate - Document - Translate - Develop - Test - Spread - Lead
Retrieved from "https://en.opensuse.org/index.php?title=openSUSE:Localization_guide&oldid=191302"