Multi-lingual Support

小灰灰 2021-11-22 19:44 271阅读 0赞

## 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”][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.

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!//期待结果和实际结果要用同一种方式解码编码。

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.//使用文本查找元素时，需要将文本解码编码进行规范化。

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和安卓都不支持使用keyboard输入非ASCII字符。

#### 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.//iOS绕开keyboard输入非ASCII字符。

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

#### 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.//安卓需要安装一个特殊的键盘软件，用于输入Unicode字符，如同输入ASCII字符一般。使用时，还要将unicodeKeyboard和resetKeyboard两个参数配置为true。使用send\_keys方法输入Unicode字符。

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`.

转载于:https://www.cnblogs.com/superbaby11/p/6068284.html

[equivalent strings have a unique binary representation]: http://www.unicode.org/reports/tr15/
[specialized keyboard]: https://github.com/appium/io.appium.android.ime