Yet another area in my 9 coding areas pseudo-localization can test is expansion and edge case handling on I/O data.
In PL5: Expanding your universe, I discussed how pseudo-localization of the user interface can test the effect of translation expansion on the look and layout. Here I'm focusing on I/O. If input/output data is pseudo-localized such that strings are significantly expanded, it can verify the handling of expanded strings. This is not just a display issue, it is also and more significantly a processing issue. Once again, I repeat my mantra: people buy software to do something to their data. If that something is not done correctly, the software is not useful to them, and they will look for software that is.
What tends to be difficult to determine is what an input field maximum is (and should be). There is a count question: should the limit be in bytes or characters? This is less important than determining how many characters should logically be allowed in a particular field. Even fields that seem fixed in one country could vary considerably in another. For example, postal codes can vary from a length of zero (no code) to as many as 12 characters (for some US territories). This brings up another question: should the length restrictions vary with the locale? (Or the localization?) The same questions hold for a minimum size.
Determining what should happen if the data is greater than the maximum is important. Should the data be truncated or rejected? Should a warning message pop-up if it's a user input field (as opposed to programmatic input), or should the user simply not be allowed to continue typing? Again, similar questions need to be answered for below minimum.
All of the above is in the realm of design rather than testing, but the point is that the desired behavior should be defined. Pseudo-localization testing will determine what is happening in certain circumstances, but if the behavior is undefined, it is difficult to decide what sort of pseudo-localization needs to be run, and how many locales should be tested.
Similar to PL5, you're looking at the layout
and aesthetics of the UI with the expanded text: is it wrapping
awkwardly? Is it overlapping other elements? Is it
skewing the overall layout? More importantly, though, is the integrity of the text: has it been truncated? Is the last character intact? (if the end of the pseudo-localized string ends in a multibyte character) Has some of the middle text been lost due to over maximum characters overlaying the previous characters in the string?
To the extent that I/O will be displayed, pseudo-l10n can help test paging on smaller devices, as well as PC and tablet. The expansion from the pseudo data will likely move things around, and it's important to determine what effect it will have, and whether it causes a problem for users working in other languages.
At the risk of boring you with repetition, this is not a substitute for testing with multilingual data, simply a quick way to get data for early testing of these important cases.