Multi-lingual Support

One problem with dealing with non-Latin characters programmatically is that, for characters with accents, there can be multiple ways of encoding the form. So, for the letter é, there are two encodings: a single combining character é (Unicode's LATIN SMALL LETTER E WITH ACUTE), and the combination of the letter e followed by the accent, ́ (COMBINING ACUTE ACCENT). In order to deal with this, there is normalization, an operation that makes "equivalent strings have a unique binary representation".

Luckily, normalizing ASCII text (i.e., text that doesn't need to be normalized) does not cause any changes, and performing the operation multiple times does not have an effect. Thus a normalization function can be called on text without risking adverse effects.

// javascript
var unorm = require('unorm');

'some ASCII text' === unorm.nfd('some ASCII text');
unorm.nfd('Adélaïde Hervé') === unorm.nfd(unorm.nfd('Adélaïde Hervé'));

So, when dealing with unicode text within a test, you need to normalize, preferably on both the text expected and that received from Appium. There are a number of ways to do the normalization, so be sure to perform the same operation on both strings!

// javascript
var unorm = require('unorm');
driver
  .elementByAccessibilityId('find')
    .text()
    .then(function (txt) {
      unorm.nfd(txt).should.be(unorm.nfd("é Œ ù ḍ"));
    });

One tell-tale sign that the problem is with the encoding of the unicode text is an assertion that fails but reports what look to be the same string:

AssertionError: expected 'François Gérard' to deeply equal 'François Gérard'
      + expected - actual

      +"François Gérard"
      -"François Gérard"

Since the error is just encoding, the output looks the same. Normalized, these should equal programmatically as well as visually.

Finders

Finding by text can also require normalization. For instance, if you have a button in an iOS app with the name Найти you may need to normalize the text within the find command.

// javascript
var unorm = require('unorm');
driver
  .findElementByXPath(unorm.nfd("//UIAButton[@name='Найти']"))
    .should.eventually.exist;

Otherwise the elements may not be found.

Text Fields

By default the automation tools for both iOS and Android do not support non-ASCII characters sent to editable fields through the keyboard.

iOS

Appium sends non-ASCII characters to iOS editable fields directly, bypassing the keyboard altogether. While this allows the text to be inputted in tests, it should be kept in mind that any business logic triggered by keyboard input will therefore not be tested.

As above, the text received may need to be normalized before asserting on it.

// javascript
var unorm = require('unorm');
var testText = unorm.nfd("é Œ ù ḍ");
driver
  .elementsByClassName('UIATextField').at(1)
    .sendKeys(testText)
    .text()
    .should.become(testText)
  .nodeify(done);

Android

Android tests allow for Unicode input by installing and using a specialized keyboard that allows the text to be passed as ASCII text between Appium and the application being tested.

In order to utilize this functionality, set the unicodeKeyboard desired capability is set to true. If the keyboard should be returned to its original state, the resetKeyboard desired capability should also be set to true. Otherwise Appium's Unicode keyboard will remain enabled on the device after the tests are completed.

Then tests can pass Unicode text to editable fields using send_keys.

// javascript
var desired = {
  app: '/path/to/app',
  deviceName: 'Android Emulator',
  deviceVersion: '4.4',
  platformName: 'Android',
  unicodeKeyboard: true,
  resetKeyboard: true
};
var testText = 'é Œ ù ḍ';
driver
  .elementByClassName('android.widget.EditText')
  .sendKeys(testText)
  .text()
  .should.eventually.become(testText)
  .nodeify(done);