Here are some basic steps a software engineer can follow to identify and analyse many potential language-specific or IME-specific issues in VisualEditor, without knowing the language in question. They do not replace the need for acceptance testing by editors who understand each individual language.
The engineer must know how to type something in the language (even one word or phrase will be helpful), how it should look, and what its code unit representation should be in the model (i.e., how each grapheme cluster in the phrase is composed and how it appears visually). It is important to watch carefully for issues with viewport scrolling, selections, keyboard show/hide, and candidate text being lost / duplicated / prematurely committed.
- Select one or more popular IMEs for the language in question. The default Gboard option for that language is often a good choice.
- On Android Chrome, edit an empty VE Standalone page (e.g. go to https://rawgit.com/wikimedia/VisualEditor/master/demos/ve/mobile.html#!pages/empty.html )
- Set "Show model" and "Update on changes" to help see if the model correctly represents the DOM as you edit.
- Type some text (multiple words, if the IME has candidate-based input). Try backspacing. Try backspacing not at the end of the text. Try backspacing part of a word (if the IME reactivates candidates). Try backspacing whitespace away.
- Select some text, then type to overwrite the selection. Select some more text and click the "link" icon. Type a link target, then edit the link text. Backspace the link out of existence.
- Add a comment (which is a focusable node in VE standalone, similar to an inline template in VE-MW) in the middle of some text. Try selecting the comment. Try selecting across the comment. Try removing the comment.
- Try creating a table, adding new cells, clicking between cells and editing cell content.
Each issue that arises should be analysed, using the debugger (see Android Chrome remote debugging). The aim is to get a detailed understanding of the underlying cause, expressed as particular interplay between the mobile IME, the browser DOM including selection and events, VE ContentEditable classes and the VE data model. (For example: "When you type 'Foo' inside an empty link, the IME modifies and commits candidate text outside the selection, but fires no event and leaves the selection and its surrounding branch node unchanged. This means the VE SurfaceObserver never observes the change and so it never updates the data model").
Certain IME-related issues are sensitive to timing, focus and selection, and stopping on a breakpoint can disrupt the IME enough that its subsequent behaviour changes. This means you cannot just step through the issue with the debugger. For such issues the VE Standalone demo page's Filibuster button can be useful; it records a full function call tree (i.e. you can see the entire sequence of function calls in the order they happened), marking each DOM state change at the point it occurred within the tree. Usually, this reveals exactly where strange behaviour starts, making it possible to place a single breakpoint and investigate without stepping.