May 25

Localizing iOS .strings files with memoQ

iosOne of the biggest buzzwords/trends in localization is currently “mobile”. And as the buzzwords go, this one is justified – there’s a lot of content being localized for mobile devices. And one of the important part of this content is the UI of mobile applications. If a developer wants to sell internationally, he/she should provide localized version of the app. This gives us a job, but also a challenge.

The big three of mobile world at the moment is Android, iOS and Windows Phone. How do we translate strings for apps from these three systems with memoQ?

  • Windows Phone uses RESX files for strings – the filter for this file type is included in memoQ.
  • Android uses XML files for strings – since there’s some flexibility with regard to file structure, I’m not sure it makes sense to create “out of the box” filter for this file type, but it’s quite easy to define your own XML filter for a particular file type (I’ll publish some tips on that soon).
  • iOS uses .strings file type – in theory the structure is quite simple and it’s easy to create a regex filter for this file type in memoQ, but in practice there are some wild variations of the “standard”, so if you want to catch all the possible information (that is comment, context ID and string itself), things might get tricky for some files.

Why the difficulties? The basic element of .strings file looks like that:

/* Comment */
"Text1" = "Text2"

Quite often Text1 = Text2, but they are different things: Text1 is an identifier for actual software string (Text2). So it makes sense to import Text1 as context ID for translated string (Text2). In most cases file structure looks like this:

/* No comment provided by engineer. */
"ID 1" = "String 1"

/* No comment provided by engineer. */
"ID 2" = "String 2"

/* No comment provided by engineer. */
"ID 3" = "String 3"

You can catch all this with one simple regex. Unfortunately .strings file specification does not require the exact structure to be followed – strings and comments can take more than one line or there can be no comment line at all. This makes things a little more difficult. Additionally strings for translation may contain placeholders like “@%1”, “%1$1”, “$2”, “%A” and so on, so it makes sense to convert them into tags to reduce word count, simplify the translation and make it more reliable.

In March this year I attended Translation Conference in Warsaw, where Wojciech Froelich (@DrAvalanche) from Argos Translations talked about pitfalls of mobile localization. Getting back home by train I’ve created a filter for iOS .strings file filter I consider quite robust.The filter imports comments (except the case of “No comment provided by engineer”, context ID and string itself in various formatting configurations allowed by the file type. Additionally regex tagger is being used to tag possible “tag” content.

The filter is available for download from here.

However, the filter is not perfect. Please note it’s limitations:

1. Filter uses UTF-8 encoding instead of assumed UTF-16le (little endian) – memoQ just doesn’t support this. My research suggests it shouldn’t be a problem, but I can’t guarantee it.

2. It’s not entirely true that only “No comment provided by engineer” comments won’t be imported as comments. Actually at the moment filter just skips comments starting with capital N, so an actual meaningful comment might be ignored. However, it will still be visible in the preview. Actually I’m still not completely convinced the comment import makes sense at all, since you do see them in the preview. Unless you want to send the file to someone else as bilingual RTF table with comments.

3. I’ve encoded all “standards” of placeholders in .strings file I could find, but there’s no guarantee you’ll encounter something else. If you want me to include your tags in the filter’s tagging mechanism, just drop me a note and send the file.

Generally, if you’ll use the filter and you’ll find it wanting, contact me sending your file, and I’ll try to improve the filter (my samples pool wasn’t huge, but diversified).

How to use the filter:

  1. Download the file.
  2. Run memoQ, open Resurce Console (Tools > Resource Console)
  3. Select Filter configurations category.
  4. Click Import new command and select the downloaded file.
  5. Create/open a project.
  6. In the Translations card click Import with options command. Document import options dialog will be opened.
  7. Select Cascading filter from the Filter drop-down and iOS .strings MP from the Configuration drop-down.
  8. Click OK.


Skip to comment form

    • Róbert Kovács on 2014/05/26 at 08:46
    • Reply

    Hi Marek,

    Great article, it will fill a gap.

    “My research suggests it shouldn’t be a problem, but I can’t guarantee it.”
    You can change the files’ encoding easily with the (free) Notepad++: Encoding > Convert to UCS-2 Little Endian. What’s more, you can check (or change) the file format too – for sure: Edit > EOL Conversions > UNIX/OSX format.

    1. Thank you, Róbert. As for the encoding conversion my method of choice would be to use Rainbow from Okapi framework, which handles encoding conversion too (among many other features).

    • Daisy on 2015/12/04 at 01:01
    • Reply

    I have an iOS string file that’s in this format. Could you please help me?

    @”text Text\u2122 text text text”

    Some strings could include: unicode entity, \n, \r, placeholders (%@%%, %@). I tried to use your filter but it was not picking up translatable strings. Thank you for your help!

    1. Hi Daisy,

      The filter was not designed to handle any strings with lines starting with @ symbol, so I’m not surprised it doesn’t work. If you can, send me a sample of the file at wasaty @ wasaty . pl

    • Omer Shani on 2015/12/15 at 12:53
    • Reply

    Hello Marek,

    Could you please send the filter or a direct link, for when I click on your link in the article I reach to Language Terminal website with no link to the filter itself.

    Thank you in advance,

    Omer Shani

Leave a Reply

Your email address will not be published.