Welcome to MetaPhrase’s homepage! Here is what you will find on this page:

• project overview
• rationale
• key app features
• further reading

Overview

MetaPhrase is a powerful tool to provide translators and software localizers with a productive and distraction-free environment for their everyday tasks. The application is designed to look very similar to a classic text editor, where the text to be translated is divided into translation units, each of which consists of a source message (displayed as a reference) and a localized variant that users can insert and edit as part of their translation task.

MetaPhrase is targeted specifically for the internationalization of the user interface of mobile applications and it has built-in support for the resource file formats used by native apps, i.e. XML on Android and stringtables on iOS. On top of it, support has been added for other common formats used in software localization, such as resx (popular in the .NET environment), PO (traditionally used by GNU gettext), JSON (in the format used by ngx-translate on Angular projects), ARB (Flutter) and Java properties.

MetaPhrase makes it easier to maintain a single set of localizable items that can be exported to separate native formats, in order to ensure consistency among different platforms.

🔝

Rationale

What’s in a name?

In general, one of the most anecdotally difficult tasks in computer science is “naming things”. The name of this application comes from the Greek verb μεταφράζω meaning “to translate” Etymologically, the μετα- prefix implies both the ideas of “after” and “beyond”, which is accurate for a translation since translations are not only expressed “on the other side” (across a linguistic barrier) but also “after” the original text has been formulated.

In the domain of open source tools for translators, this prefix is shared in a broader family of applications – such as MetaTerm for terminology management and MetaLine for bilingual corpora alignment.

Scope definition

Mobile app localization is a subtype of software localization and shares many of its constraints and pitfalls. In the first place, for example, the strings to be translated are relatively short messages used in some part of the user interface, thus appearing rather in isolation and non-contextualized.

In the second place, there are some length limitations, since messages are not bound to appear printed on paper or on a web – site where there are virtually no space constraints – but in UI elements (buttons, tab bars, segmented controls, labels, etc.) where the amount of available space is limited.

In the third place some parts of the messages used in UI elements my contain varying parts that are only known during the program execution and are substituted (or rather “interpolated”) at runtime, so they are marked with some special format specifiers which indicate the type of value (string, decimal number, floating point number, and so on…).

Finally messages should be adapted for different plural forms depending on the structure of the target language and mobile SDKs provide mechanisms to select the appropriate form of the message depending on the value which is, as in the previous case, only known at runtime.

On top of all of that, if a development team is maintaining different codebases (e.g. an Android native app and an iOS native app) and they want to use the same set of strings for both, another problem arises since the two platforms use different resource file formats which are incompatible, even format specifiers have different forms (e.g. %s for strings on Android whereas in the iOS world %@ is much widely spread for any arbitrary object having a description selector).

Even if the same keys are used to reference the string resources, adding a new language in both platforms or updating a translation (either incrementally adding new strings or changing existing ones) can become extremely painful and error-prone.

Current state of the market

How does it compare with existing alternatives, especially in the field of mobile application development?

• in Xcode, localizable files are are treated as text files and they are only shown one at a time. This implies for each message only the key is displayed, which makes it difficult to work on it as a translator because the reference (source) messages are not displayed any more after a translation has been inserted. MetaPhrase solves this issue by always showing both the key and the source variant of each message.

• in Android Studio, if editing the XML resource directly the problem is the same as Xcode but there is a translation editor designed specifically for string resources. In this case, all the languages are displayed at the same time making it difficult to keep focus during translation if the project contains a large number of languages (e.g. it may happen to edit the wrong column by mistake). Special care has been taken in MetaPhrase to provide only the information needed without cluttering the UI with too much information (e.g. local variants for other languages are not included).

• OmegaT, another Java-based translation editor very well known in the open source world (and one of the most complete solutions out there) supports Android resoures but not iOS stringtables (which are supported in MetaPhrase).

• there are several open source translation tools out there, the most known are Virtaal (GTK-based) and Lokalize (Qt-based). Unfortunately, as far as software localization is concerned, they are PO-centric (PO being the standard format for messages used by GNU gettext and similar popular toolkits in open source development) and having to convert back and forth to PO from string tables and XML resources is not so straightforward. MetaPhrase provide seamless integration with XML and stringtable formats allowing to import from and export to each of them by design.

• there are many popular online platforms for localization which leverage a crowdsourcing approach and are used to have users themselves localize the applications they use. This is an interesting approach because it allows to save money (and time) but often strings are displayed without any context (not even message keys), there is no glossary/translation memory and there is no control about how the collected data are being used by the third party platform. Some servers can be hosted on a local machine thus allowing full control on the data (e.g. Pootle) but they require a remote server to be run and may be out of scope for small mobile projects.

In any case, one of the main strength point of MetaPhrase is that it abstracts away the resource file structure and allows to reason in terms of message “keys” and message “local variants”, allowing to generate resource files merely as an exchange format. This makes it easier to manage multilingual projects over time (when different incremental versions of the localized application are released by maintainers).

🔝

Key features

Editor

The translation editor is the main screen of the application and it has two modes: the source (base) mode and the target (localized) view.

The source mode does not allow to insert any translation but, instead, to change the source messages. It is intended for developers and project managers, whenever they need to update the source text. An update in the source text will affect all the target languages. It this mode, only the message key and source text are displayed and messages can be marked as “unstranlatable”, making them disappear in the target languages.

Conversely, the target mode allows translators to insert a localized version of each message for the translatable messages. For each message the key and source text are displayed (but can not be changed) whereas the translation in the target language can be modified.

Import / Export

MetaPhrase is designed to integrate in the most frictionless way with the standard localization formats used for mobile application development: iOS stringtables (aka Localizable.strings) and string resources on Android (aka strings.xml).

Support for .resx files, a common format used in Windows applications and in general in the .NET environment was integrated as well as suport for JSON resources in the format of the popular ngx-translate library. The application also partially supports the PO format (very popular in projects using the GNU gettext utility) and Flutter ARB resources.

MetaPhrase can import from and export to resource formats and it allows to manage some of the properties that these formats allow (e.g. marking some strings as untranslatable which on Android is achieved with the translatable="false" attribute).

Plural forms (quantity strings) are not supported yet, if requested it may be added in a future release.

Translation memory

Fuzzy matching in the translation memory (TM) is a key feature to ensure consistency both in-project and across different projects and to leverage the work that has already been done (this speeding up the localization process). The content of the TM panel is updated every time a new messages is opened for translation and shows all the matches that are above a similarity threshold (configurable in the settings screen).

The best match can be inserted via a shortcut and can be modified afterwards if needed. In addition to the “Matches” panel, the content of the TM can be browsed and searched as if it was a concordancer from the “Memory” panel.

Memories can be exported and imported to/from TMX (standard Translation Memory eXchange format). The application is designed to work as much as possible with standard formats, so TMX is used also to save whole projects and even for the internationalization of its own UI.

Glossary

Glossaries can be considered the second golden tool to ensure consistency and save work. Whenever a message is opened for modification, the source text is analyzed and its words are stemmed, then matched against the content of the application glossary to show correspondences in the glossary panel.

Glossary entries can be added on the fly by selecting a term in the editor, right-clicking on it and selecting the “Add to glossary” menu item. It is also possible to import and export glossaries in CSV format.

Validation

One of the most important features of this project is the placeholder validation. Placeholders are indicated by special sequences of characters (known as format specifiers) such as %1$d or %2$s that convey information both about their position (the optional digit before the $ sign) and the data type (the letter after the % sign). An error in a format specifier by the side of the translator may lead to the application crashing or failing to display the message properly, so their correctness if of vital importance for the localization.

When running the placeholder validation, MetaPhrase scans all the messages in the current localized variant of the project and detects whenever a placeholder is missing or has been erroneously added in the target message. By clicking on each row in the panel, the editor will scroll to the corresponding message for the translator to correct the mismatch.

In addition to placeholder validation, it is also possible to run a global spelling check on all the localized strings. Spelling is also checked whenever any message is opened for editing.

Machine translation

MetaPhrase can also integrate with the MyMemory service for machine translation. The results are displayed in the bottom panel and can easily be copied into the translation editor.

🔝

Further reading

If you are a translator or software localizer and you would like to start using the application, please check out the User Manual for a more detailed description of how to use its main features. Do not forget to contact the maintainers of the project if you find any bug or would like to request a feature.

If you are a developer and would like to contribute to the project, have a look at the dedicated section Tech Notes for a better explanation of the architecture and the technologies involved in the implementation of this project and find some instructions about how to build from source and contribute to the project.

🔝