This app has already two APIs for machine translation. What is the added value of a built-in database with translation rules?
The rule database helps you to better localizate your apps in two important ways:
- Compensate for flaws of machine/AI-based translation services. Like accurate localization of texts consisting of just one word: your app buttons. All APIs struggle with this.
- More flexibility, like translating via a dictionary or another API. Or you work with a translator who prefers flat files instead of XLIFF XMLs. How this app supports these so-called manual localization workflows is explained here.
APIs love (long) sentences
But they struggle with correctly translating single words. Like the Close button on your app (assuming English as base language). For localization into French, a translator API has to choose from at least these 18 different options:
And the correct answer is…… none of the above:
The verb fermer (to close) is commonly used in apps and websites localized in French. And only this verb form (infinitive), not the imperative forms ferme (informal) or fermez (formal), which are a good choice for buttons in other languages.
Re-using localized texts, from other apps or from lists provided by your translators, results in more consistent and understandable buttons in your app. As you avoid the flawed and sometimes random machine localizations. And it can help you to stay within the free API limits. This is the reason the rule database exists and that it is checked first (if not suspended) before localization is attempted via an API.
Rule database structure
Every row in this database has the following seven columns. A valid rule must support translating a default string (in base language) to a localized string (in a specific local language). Therefore the string and language columns are mandatory. The other three, optional, columns can be used for more specific localizations.
When updating or inserting rows, all columns are considered key, except for Localized string (the only value column). The optional columns must be empty on both sides or have the same value (case sensitive). The language pick lists contains over 200 of the most commonly used values from Xcode: all 2 letter ISO 639 values (en, fr, de, hi etc.) and the most widely used locales (en-GB, pt-BR etc.).
Because this app relieves you from the effort of learning the XLIFF format, the naming of the columns is in line with Xcode only. Here is the mapping In case you do want to use and XLIFF editor:
| App | XLIFF |
|---|---|
| Project/Catalog | original attribute of file tag |
| Key | id attribute of trans-unit tag |
| Base language | source-language attribute of file tag |
| Default string | value of source tag |
| Local language | target-language attribute of file tag |
| Localized string | value of target tag |
| Comment | value of note tag |
Specific and generic rules
Translation rules you capture using functions in this app are specific to one string catalog in one project and for one localization key only. Or even more specific, when comment (instructions or context for your translator) is filled as well. Like the top row in the screenshot below.
When using the rules database to localize strings exported from Xcode, all columns that are filled in the rule must match. If there are multiple rules with the same combination of Base language, Default string and Local language, like the screenshot below, the rule with the most matching columns is selected.
The bottom row only requires Default string to match, if you want to localize to German from base language English (U.S.). Regardless of project, catalog name, key and/or comment value, this rule will produce a successful localization. This row, with only the four mandatory columns filled, is therefore the most generic one. You can generalize your rules to make them re-usable for other apps.
Manipulating localization rules
The Rules screen of this app offers the following options:
- Import from file: either tab-separated .csv or JSON. If you need a template, create one new row, select it and click on Export selection to file.
- Export selection to file. This button is disabled if no rows are selected.
- (Un)select all. If one or more rows are not yet selected, all rows will be selected. If all rows are selected, all rows will be unselected. You can only select filtered (visible) rows.
- Delete selection. This button is disabled if no rows are selected.
- New rule. See screen shot above. The values you select for Base language and Local language are preserved for the next New rule you create. If you need more than a few rules, using a spreadsheet followed by .csv import or your own script followed by JSON import is more efficient than this screen.
On top of the above five buttons, you can right-click on rows or a selection of rows to insert, edit or delete.
Filtering and sorting translation rules
By default, all rows in the database are shown. This is indicated by the disabled Clear Filter button on the top right.
Powered by an efficient SQLite database, this app can easily handle tens of thousands of localization rules. For quickly viewing a subset of these, use the above filter bar with boolean logic.
Both search text are case sensitive. As mentioned in the hint text, a wildcard can be used to represent “something”, with the format ?* or ?* or the less precise * or ?. Combined with ‘Not in’ you can filter on empty optional columns. As a wildcard value plus ‘Not in’ is interpreted as “nothing”.
You can sort on any of the seven columns by clicking on the column header. An up or down arrow next to the column name indicates the sort order applied.
Supported file formats
You can import and export translation rules as tab-separated .csv. This format allows your text to contain quotation marks. If your strings contain tab characters (\t) then importing this format can cause skipped rules. Consider using .json instead.
When importing, the format is automatically detected. Before exporting, select .csv in the Rules database section of the Settings screen (see below screenshot).
Files in .csv format can be easily edited with spreadsheet software (LibreOffice, Excel).
Alternatively, you can import and export rules in .json format.
This file type is the best choice for processing by your own scripts or other software.
Rules database options Settings screen
Get this Apple app localization tool
