Brainstorming …….

In our era, everyone put down their heads staring at the phone, no matter it’s an android phone or an iPhone, on the bus, train, plane, even walking and driving. What are we staring? Apps!!!!!! I said everyone, meaning girls who do not speak English in China, boys who play rugby in France, dogs … Yeah, we are in a globalized era who speak different languages but doing the same things. We use facebook, instagram on android/iOS platforms in Spanish, Japanese, Russian, Arabic, etc. This lead to a problem — How do engineers manage localizable strings on different platforms? The most effective ways is to manage them altogether regardless of the platform, since the UI in different forms are almost identical.

Hmmmmmmmmmm… So the challenge is how do we centralize and manage strings for all platforms? I mean, in the “one stone kills two bird” fashion. Then, we started to use the most advanced and cheapest assistant, “Hey Google, search ‘cross-platform string management’!”

TAAAAAAAADOWWWWWWW!!!

We discovered Twine. Twine is a command line tool for managing your strings and their translations. These are all stored in a master text file and then Twine uses this file to import and export localization files in a variety of types, including iOS and Mac OS X .string files, Android .xml files, gettext .po files, and jquery-localize .json files. This allows individuals and companies to easily share translations across multiple projects, as well as export localization files in any format the user wants.

Now we need a GUINEA PIG! What’s the Qualification?

    1. It has to be open source, otherwise we are too poor to PAY for any.
    2. The strings must be internationalized since none of us is an engineer. [Shrugged.gif]
    3. It has to be available on both iOS & Android because it is EXACTLY what we are testing.
    4. LAST but not the lease, localizable strings are not centrally managed YET…

TAAAAAAAADOWWWWWWW!!!

WE FOUND WIRE!!!!!!

Wire advertises itself as THE MOST SECURE COLLABORATION PLATFORM. It supports secure messaging, file sharing, voice calls and video conferences. All information is protected with end-to-end encryption. So, it sounds cool and I might actually try it latah~~

Let’s get our hands dirty NOW…

We followed the following steps:

1. Install

As a Gem

  • Twine is most easily installed as a Gem.
  • $ gem install twine

From Source

  • You can also run Twine directly from source. However, it requires rubyzip in order to create and read standard zip files.
  • $ gem install rubyzip
  • $ git clone git://github.com/mobiata/twine.git
  • $ cd twine
  • $ ./twine –help

Make sure you run the twine executable at the root of the project as it properly sets up your Ruby library path. The bin/twine executable does not.

2. Creating Your First Twine Data File

The easiest way to create your first Twine data file is to run the consume-all-localization-files command. The one caveat is to first create a blank file to use as your starting point. Then, just point the consume-all-localization-files command at a directory in your project containing all of your localization files.

  • $ touch twine.txt
  • $ twine consume-all-localization-files twine.txt [Resources/Locales] –developer-language en –consume-all –consume-comments

3. Validating Your First Twine Data File

validate-twine-file

  • This command validates that the Twine data file can be parsed, contains no duplicate keys, and that no key contains invalid characters. It will exit with a non-zero status code if any of those criteria are not met.
  • $ twine validate-twine-file /path/to/twine.txt

4. Generating translation files to send to translators

  • This command generates PO file from twine.txt.
  • $ twine generate-localization-archive twine.txt LocDrop1.zip -f gettext

5. Push translated files to Twine Data file

  • $ twine consume-localization-archive twine.txt LocDrop1_translated.zip –format gettext

6. Push translation from Twine Data file to iOS/Android strings files

iOS

  • Make sure you have [lang]-[LOCALE].lproj folders under Resources/. Twine will generate Localizable.strings files in each language folder.
  • $ twine generate-all-localization-files twine.txt wire-ios-develop/Wire-iOS/Resources/

Android

  • Make sure you have values-[lang]-r[LOCALE] folders under res/. Twine will generate .xml files in each language folder.
  • $ twine generate-all-localization-files twine.txt wire-android-master⁩/app⁩/⁨src⁩/⁨main⁩/res

 

After these 6 steps, here are what we got:

Voilà Voilà Voilà Voilà Voilà Voilà

French UI

здесь здесь здесь здесь здесь здесь 

Russian UI

In this exercise, we just tried out the basic function of TWINE, and there are more stuff to explore:

  • Extend Twine to support other l10n file formats
    • E.g. XLIFF, .properties, .resx, .stringsdict
  • Output multiple l10n files
    • Now: localizable.strings + infoPlist.strings > twine.txt > localizable.strings
    • After: localizable.strings + infoPlist.strings > twine.txt > localizable.strings + infoPlist.strings
  • Automate the workflow
    • Push new strings to Crowdin
    • Pull translations into the twine master data file
    • For every new build, the platform specific resource files will be generated

You are more than welcome to try it in your spare time, and feel free to discuss with me!