Development/gettext-design

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Overview
• Reporting Bugs
• How to build
• Code Overview
• Git Commands
• Debugging
• EasyHacks
• Release Plan
• FAQ
• Developers
• Extensions
• → Open Issues

This page was marked as inactive and is retained for historical reference. Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as one of our mailing lists.

Translations using gettext

This page is about how one could start to use gettext in LibreOffice.

migration plan

The migration to gettext should be as smooth as possible. Therefore, it should be initially added as an optional way to provide translations. If the translation cant be found in the traditional res-files, a translation via gettext is tried.

initial proposed design

• a gettext textdomain should be the equivalent of a current res-file.
• the directory of the current res-file is the catalog location to set via bindtextdomain. E.g. for a res-file named /foo/bar.res the translations are searched at /foo/locale/LC_category/bar.mo
• the msgid (the text to translate via gettext) should be the english string, as retrieved from the res-file.
• the msgctxt (the context for the text to translate via gettext) should be the decimal representation of the RES_ID to translate.
• a locale providing translations via gettext still needs the english localization installed:
  • for non-string resources (dialog layouts etc.)
  • to get the initial english string to translate via gettext from the res-file

code start points

• All SDF translations pass the ResMgr in the library tl: https://opengrok.libreoffice.org/xref/libs-gui/tools/source/rc/resmgr.cxx
  • the ResMgr::IsAvailable() function will need to be modified: https://opengrok.libreoffice.org/xref/libs-gui/tools/source/rc/resmgr.cxx#1086
  • the ResMgr::GetResource() function will need to be modified: https://opengrok.libreoffice.org/xref/libs-gui/tools/source/rc/resmgr.cxx#1138
• For string resources a fallback via const char *dpgettext (const char *domain_name, const char *msgctxt, const char *msgid); with the parameters described above should be implemented.
• For non-string resources for a gettext locale, a fallback to english resources needs to be implemented.

open points

• Do we have non-string localized resources (e.g. different dialog layouts for some languages)?

.res file format allows localization of dialog layout but l10ntools don't. So the answer is no, we don't have non-string localized resources. AndrasTimar 2011-06-15T16:24:09 (CEST)

• What do we do about localized stuff in icons/themes? Are those really needed or used?

Localized icons are handles elsewhere (artwork repository) and those are not compiled into .res files. AndrasTimar 2011-06-15T16:24:09 (CEST)

• String encoding: should we go directly with UTF-8 in the file format, even if LO does not use it internally too much?

Currently .res files use UTF-8. AndrasTimar 2011-06-15T16:24:09 (CEST)

• since we originally used a RES_ID->string mapping and use a english_string+RES_ID->string mapping now, l10n will increase in size (unless we are gaining more by not duplicating the non-string resources in the res-files, but that is unlikely). Should we maybe use the empty string as msgid and only use the context/RES_ID as key? That might make using standard gettext tools much harder though, spoiling the fruits of this effort.

Total size of .mo files compiled from current .po files (excluding source of .xml files, installer files and help) is slightly less than the total size of .res files. AndrasTimar 2011-06-15T16:24:09 (CEST)

• Threads: Do we need special considerations for threading?
• Is there a way to migrate the english strings directly into the source once we have this setup and all l10ns use gettext? Also: Can we 'unimplement' the notion of localized non string resources in ResMgr?
  • We could then remove the strings from the res-files and only use those for "real" resources.
  • What about help?
  • Would we still need a context, because otherwise we get dupes?
• Can we use Boost.Locale as our libintl implementation: http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/messages_formatting.html
• Should we patch libintl to use memory mapped .mo files on Windows, too? This might even be an Easy Hack, the API is quite straightforward.