Another aspect to be aware of is that English is often much shorter than the equivalent translated text, especially on buttons with text labels. I remember many years ago we used a rough rule of thumb of always doubling the space used for English to ensure there was enough space for the translated text.
While developing, it's a good practice to have at least "lorem ipsum" or auto translated versions of the phrases in your product, if you're targeting multiple languages.
Likewise though, character based languages like Chinese CAN be a lot more compact than English. But counterpoint, those same languages have a different internet culture where they will put more information in headlines. Random website I looked up; https://cn.chinadaily.com.cn/ has a small header in a sidebar:
数读中国 | 韧性强活力足信心稳 外贸外资稳中提质
But it translates to something that's three times as long in English:
Data Reading China | Resilience is strong, vitality is sufficient, confidence is stable, foreign trade and foreign investment are stable and quality is improving
Another thing to keep in mind for development: right-to-left languages like Arabic, Hebrew, Persian, Urdu, Kashmiri, Pashto, Uighur, Sorani Kurdish, Punjabi, and Sindhi. I was lucky to be involved in a very international website that also had a Hebrew version, the CSS developers (another luck, we had dedicated CSS developers) even made the site layout right-to-left on RTL languages.
Years ago when I worked at Microsoft, they had a "pseudo localization" tool, at least for Visual Studio, that would inject backwards text, longer text, etc... It was gibberish, but it gave QA instant feedback on whether the UI would accommodate the localization process.
I did a quick web search, and it appears to be a well-understood practice, even covered in a different Shopify blog:
I like to have a "double length" localization mode that doubles the English text; useful for fixing some layout issues while waiting for translations.
A separate toggle to underline everything going through the localization system (or adding some __delimiters__ around it if you don't support rich text) is great for spotting text that is not running through localization yet.
Once you have translations back, a "longest length" translation mode is more useful. It picks the longest translation for each token, no matter what the language. Confusing to look at, but great for seeing only the places where you actually have text-fit issues.
Another tip I've found in pseudo-localization is to add in lots of emoji to the text. That can help check some Unicode assumptions/encoding issues in your localization pipelines in ways English readers can better visualize.
One common problem on macOS that International users often complaint about is how messages in their native language are really long so they get cut off, and they're never fixed despite being reported for years. But if even Apple, a multi-Billion dollar company, struggles with these problems, I'm not sure there's any easy solutions.
Non-latin fonts also have different glyph widths. For example cyryllic text might be same "length" but glyphs in a system font might be wider hence overall the string needs more space.
On Apple platforms, translators can not only translate strings but also adjust the actual layout of the UI. Sure that's adding more work but is probably worthwhile.
Comments
Another aspect to be aware of is that English is often much shorter than the equivalent translated text, especially on buttons with text labels. I remember many years ago we used a rough rule of thumb of always doubling the space used for English to ensure there was enough space for the translated text.
While developing, it's a good practice to have at least "lorem ipsum" or auto translated versions of the phrases in your product, if you're targeting multiple languages.
Likewise though, character based languages like Chinese CAN be a lot more compact than English. But counterpoint, those same languages have a different internet culture where they will put more information in headlines. Random website I looked up; https://cn.chinadaily.com.cn/ has a small header in a sidebar:
But it translates to something that's three times as long in English: Another thing to keep in mind for development: right-to-left languages like Arabic, Hebrew, Persian, Urdu, Kashmiri, Pashto, Uighur, Sorani Kurdish, Punjabi, and Sindhi. I was lucky to be involved in a very international website that also had a Hebrew version, the CSS developers (another luck, we had dedicated CSS developers) even made the site layout right-to-left on RTL languages.Years ago when I worked at Microsoft, they had a "pseudo localization" tool, at least for Visual Studio, that would inject backwards text, longer text, etc... It was gibberish, but it gave QA instant feedback on whether the UI would accommodate the localization process.
I did a quick web search, and it appears to be a well-understood practice, even covered in a different Shopify blog:
https://www.shopify.com/partners/blog/pseudo-localization.
I like to have a "double length" localization mode that doubles the English text; useful for fixing some layout issues while waiting for translations.
A separate toggle to underline everything going through the localization system (or adding some __delimiters__ around it if you don't support rich text) is great for spotting text that is not running through localization yet.
Once you have translations back, a "longest length" translation mode is more useful. It picks the longest translation for each token, no matter what the language. Confusing to look at, but great for seeing only the places where you actually have text-fit issues.
Another tip I've found in pseudo-localization is to add in lots of emoji to the text. That can help check some Unicode assumptions/encoding issues in your localization pipelines in ways English readers can better visualize.
One common problem on macOS that International users often complaint about is how messages in their native language are really long so they get cut off, and they're never fixed despite being reported for years. But if even Apple, a multi-Billion dollar company, struggles with these problems, I'm not sure there's any easy solutions.
That reminds me about german version of TES Oblivion with its "Schw. Tr. d. Le.en.-W." for "small potion of healing"
Non-latin fonts also have different glyph widths. For example cyryllic text might be same "length" but glyphs in a system font might be wider hence overall the string needs more space.
On Apple platforms, translators can not only translate strings but also adjust the actual layout of the UI. Sure that's adding more work but is probably worthwhile.