Coding for the world, part 9: Casing, space, and commotion behind the scenes
Today we have a nice mix of different subjects to talk about. All caps or no caps: that is the question. Casing can make a big difference within the UI and for localization. In English we have a lot of words that are very short; but when those are translated, they can be surprisingly much longer than the English source, and UI space can get cramped or messy when you use code to glue pieces together. Let’s dive right in.
The importance of casing
As a developer you sometimes need to write UI string text yourself due to time constraints, or perhaps there is a lack of UI copywriters in your company. Be aware that casing can be very important for localizable content. Casing can give the linguists a clue on the category of the content’s meaning if it is a button label, an option label, or a title. You might ask, why do the linguists need to know, can’t they just go ahead and translate? Here the answer: Context is always important for localization.
In short, writing style can vastly differ—for example, for the content “Add user”, depending on whether it’s a button label or a title. If not done right, inconsistencies may occur which lead to confusion and irritation, not only for linguists, but also for your users.
For this it is also important to write separate strings and not use the same string for a title and a button. Write one string for the title “Add User” and another for the button “ADD USER”. Reading a title style on a button would not give your audience the best experience.
Example:
"AddUserButton": "ADD USER",
"AddUserTitle": "Add User",
And here in the German translation, notice that the translation style is different between a button and the title.
"AddUserButton": "BENUTZER HINZUFÜGEN",
"AddUserTitle": "Fügen Sie einen Benutzer hinzu",
Also, it’s very important to keep the capitalization consistent! If your options listed in a dropdown menu are capitalized a certain way, like “Edit user”, then the next option should be capitalized the same way: “Change user” and not “Change User”. This applies to all the UI string content. For instance, if option labels within the UI don’t end with a full stop, don’t start using full stops for option labels (except, of course, if you have two sentences for an option label).
If you don’t have any UI copywriters in your company, create a simple style guide on how to write for the different UI elements to keep everyone on the same page. This way you can establish best practices within your developer team.
Suddenly there was no space left
Sometimes the spacing within the designed UI can be tight and the English luckily snuggles right in. Good for the English version of your product! Did you know that the shorter the UI content is, the more it can expand percentage-wise during translation? Up to 10 characters can have a maximum expansion of 300%! Wow, right?
So, text expansion is an important part to factor in while coding and designing a product. One approach is to use pseudolocalization. With pseudolocalization you can test your product to see how well the design holds up when the text expands. There is also the opposite. Some languages will take less space, such as Korean, which can result in a design that looks empty and bare.
A best practice is to always factor in more space than the English content occupies. Code a dynamic and flexible UI to not run into spacing issues during QA. This way you will have less headache and more time to focus on other issues you may encounter.
Commotion behind the scenes
Imagine this scenario: The localization of a product is done, all content is implemented and the QA phase starts. Sometimes during QA I am amazed by what I am seeing in the final localized product:
- German suddenly has the headline casing of the English version
- Japanese has English commas
- The French has no space before the colon
- Grammar is weird for Spanish
- English bits and pieces pop-up here and there
- Turkish button labels are incorrect
How can this happen? The reason is that behind the scenes, there is sometimes a flurry of activity which is not visible to us during localization. Thankfully this is not a lost cause, but just a matter of knowledge and thinking of localization during coding.
Best practices to avoid commotion behind the scenes
- No enforcement of casing: Write the content in the source code as it will be seen later in the UI. If you have a button labeled ADD USER, send the string “ADD USER” to localization. It’s the same with title casing: if you have a title “Add User”, send the string “Add User” to localization. If you only have one string “add user” and use it for the button and the title and have code to control the casing, you are in trouble: English headline casing does not apply to all languages. In addition, for some languages the lowercase characters do not match the uppercase characters. For example, a given lowercase character can correspond to more than one uppercase character.
- As an avid reader of my blog posts, you know that keeping everything together is very important: even the small things, such as a colon or a full stop, need to be sent out to localization within the context. Sending out “Read the instructions” and coding a colon : later after translation does not work for all languages. Some languages have a space before the colon, some use a different symbol for a colon, or don’t use colons at all. For this example, you need to send out “Read the instructions:”. This keep-everything-together rule applies to all content. Piecing bits and pieces together after receiving the translated content backfires almost every time. The word order and grammatical rules of other languages just don’t match the English language. There will be changes in sentence structure in other languages.
- For list markers like A, B, and C, other languages may use different delimiters. Use a format list method that creates locale-specific listings.
- Hardcoding is, in most cases, not a solution when it comes to other languages. Please make sure you send everything out for translation that is localizable. Even if you have content that might need to be kept in English, send it out anyway and it can be left as is and dealt with during the localization process. Indicate that this is content not to be translated (DNT – Do Not Translate).
Example:
"ProductNameDNT": "DocuSign"
Phew. We covered a lot today! I hope you will return for my last and final blog post when I talk about genders and pluralization. Until then, sunny greetings from the linguist that you can trust!
- Coding for the world
- Part 1: Why should I care about localization?
- Part 2: Keeping it together—or is separation a thing?
- Part 3: It is all about those clues
- Part 4: Everyone talks about recycling; we are not, or are we?
- Part 5: What’s in a name?
- Part 6: Time, money and arrangements
- Part 7: A form is a form. Wait. What?
- Part 8: Politics and your involvement
- Part 9: Casing, space, and commotion behind the scenes
- Part 10: The one with the genders and pluralization
Note: Thanks to Carlos Barbero-Cortés of DocuSign for consultation and feedback.
