I18n Gremlins come in many nasty and disruptive forms. Maybe a concatenated or embedded string. Perhaps the date format shows up wrong or you see square boxes and gobbledegook in your user interface. They are annoying bugs for localized products that detract from your product quality for worldwide users. Typically, they are found late in a development cycle and sometimes sit for months to years in bug tracking backlogs. But you can find these Gremlins and eliminate them as code is being written, when internationalization (i18n) is fast and easy to fix. Let me explain. When developers are creating new products and features, it is easy to inadvertently add i18n Gremlin issues. Some are pretty obvious, like embedding a string (messages in a product interface), rather than using a locale framework and a key, so that words that will need to be translated are all in resource files. It’s one of the most basic practices for i18n – writing software that can be quickly and efficiently translated for worldwide customers. Other i18n Gremlins are a bit more complex. For instance, embedding a font that might work fine in English but is illegible in Chinese, or forgetting to pass locale into a calendar class. We came up with the term Gremlins because, like the mythical sprites they remain hidden and cause sabotage. i18n Gremlins aren’t immediately obvious and often are not found until later, when it costs much more in time and distraction to locate the gremlins’ source and fix the issues. Here are some of the fundamental areas of i18n Gremlins that Lingoport’s Globalyzer software will detect as developers write software: 1. Concatenations Issues: It’s like an Embedded String which cannot be externalized as such. In many languages the word order is likely to be different, so translations will read terribly. The string first needs some redesign. This one comes in all kinds of shapes and sizes. Here is a concatenation example: “Welcome ” + username + ” to our Rebel Outfitter store” Remedy: The typical remedy is to create a parameterized strings and keep the parameter variables outside of the string itself. For instance, the parameterized string may look like “Welcome %{userName} to our Rebel Outfitter store”. 2. Embedded Strings Issues: When you change locale, the string stays the same. The string was hard-coded in the application and is resistant to locale changes. For example if there was simple code that looks like: String d =”All the young ones”; String e =”Having a good time”; Remedy: Externalize the Embedded String from the source code. Generate a Key/Value pair in a resource file, refer to that key in the code to retrieve the value. The value is the string itself. With your locale framework, you can then retrieve the string from a locale dependent resource file. When the string is externalized, the code looks like: String d =getString(“JAVA_TESTSTR_105”); String e =getString(“JAVA_TESTSTR_106”); And the key/value pair in the resource file looks like: JAVA_TESTSTR_105=All the young ones JAVA_TESTSTR_106=Having a good time 3. Locale Sensitive Methods There can be hundreds o these locale sensitive methods, functions and classes depending upon the programming language. They effect issues like date formatting, numerical formatting, character encoding, currency handling, measurements and more. Here are some examples: Date/Time Format Issues: The application may look right but provides the wrong information. If the date shown is 05/06/07 independently of the locale, it means: May 6, 2007 for an American June 5, 2007 for a Frenchman 2005, June 7 for a Japanese Remedy: The application needs to format the data based on the user’s locale and, for instance, show May 6, 2007 as 05/06/07 to an American user 06/05/07 to a French user 07/06/05 to a Japanese user In addition, the date/time may be displayed using Time Zone. The entity or value itself may need to be a GMT date / time. Currency Format Issues: The application displays the same amount whatever the locale/region of the user. For instance, a Canadian user sees $5000 and may think that in Canadian dollars when it’s in US Dollars. Remedy: The application needs to format the number, display the symbol, and most likely use some exchange rate to display the actual currency amount for the user’s language / region. 4. General Patterns Issues: This gremlin may take the form of an encoding like ISO8859-1 when UTF-8 is required, or set a font that cannot be used in Chinese, even decides a format output. Remedy: Make sure to check for each pattern to decide if it is a General Pattern, if more need to be added to your specific application, and how to refactor the code. 5. Static Files Issues: The application serves the same file, maybe a video or a legal HTML file, independently of the locale. For example, a Chinese video is shown to a Russian application user. For example: placemarkAttributes.imageSource = “./img/marker.png”; Remedy: The locale framework needs to provide for an internationalization way to refer to the file so that a locale with a static file name will result in serving a Russian video to the Russian user. All of these types of Gremlins are quickly and easily found using Globalyzer, which can detect i18n Gremlins in a number of ways: In the developer’s IDE – A developer can add Globalyzer i18n detection to their development environment and see i18n issues as they work. During commits or pull requests: As a developer submits her day’s work, a Globalyzer scan can run automatically illustrating any i18n issues. That makes it easy to fix any i18n issues that can arise and then move on. Dashboards for specific repositories, entire development products, or software across your enterprise – gives a broad view of i18n readiness, while also enabling issue drill downs, assignments and other management features. —————————————– Learn more about i18n Gremlins: Webinar Recording: https://lingoport.com/webinar-common-i18n-Gremlins-and-how-to-squash-them/ To see what Gremlins look like within an example application visit: https://rebel.lingoport.com/RebelOutfitters.DarkSide/. Look for the little gremlin characters throughout the site and hover your mouse over them to investigate further. And for a dashboard view see: https://sandbox.lingoport.com/project/extension/lingoport/overview_page?id=RebelOutfitters.DarkSide%3Ascan&qualifier=TRK There are other problems of course that our software suite will solve for you, so that you localization is fast and in tune with software development. To discuss your own localization process, continuous localization and Linguistic QA, please reach out to Gremlins@lingoport.com. Share on Facebook Share on Twitter Share on Google+ Share on Pinterest Share on Linkedin Share on Tumblr Share on Vk Share on Reddit Share by Mail