Qingjiang Yuan

pageicon Tuesday Oct 17, 2006

Does it take longer time to resolve i18n bugs than other bugs? Why?


I recently did some bug finding/resolving trend analysis, looks like even when i18n bugs are found very early with higher priorities, product teams are still spending more time on those bugs, here are some possible reasons:
  1.  Not a lot of engineers are familiar with i18n issues, so only one or two engineers in a team can solve i18n bugs while many engineers can share the responsibilities of non i18n bugs.
  2.  Some managers, sales or marketing people think the time to English speaking market is more important than other regions, especially when there are less resources, so they push the product team to allocate more resources on non i18n features.
  3.  Most of the time i18n bugs are found very late and thus engineering team don't have enough time to fix them, core bugs can be found by anyone in the development team or QA team at any time but i18n bugs are usually found during official i18n testing by following some test cases using some pseudo l10n data or when the product is localized into some other languages and native speakers are doing l10n testing, in either case, it's already behind the regular testing cycle and thus i18n bugs are fixed more slowly than other bugs.
pageicon Wednesday Oct 11, 2006

When should we think about i18n in a software development life cycle?


No need to rewrite anything since it already exists on internet :-) http://www.moraviaworldwide.com/Services.aspx?AliasPath=Services/Internationalization&CultureAlias=en-US

The ideal time to start thinking about internationalization is at the conceptual stage of a product development life cycle. It is often much easier and less expensive to build internationalization support before a product is designed or developed. Contrary to some opinions, we believe that internationalization is often necessary if localization is not. For example, the ability to run an American English application on a French or Spanish OS is important regardless of whether the user interface is to be localized into these two languages. Along with incorporating internationalization into the development cycle at a very early stage, it is equally important to educate the development team on internationalization best practices to minimize re-work. Finally, testing plans to address international support should be an integral part of the core product testing.

Why i18n?


Recently I was at a meeting to discuss i18n with a partner, their product is written in JavaScript and has no i18n framework yet, what's interesting is they don't think they need an I18n even though they will have to translate their product web interface into some other languages,for example, their approach to support Japanese is to translate all of the strings in all JavaScript files into Japanese and then they will get a Japanese version of their product, to support both Japanese and English, they will ask customers to install two instances, or two websites, one for Japanese, one for English. I couldn't say anything at the meeting because I was astonished, I did send them a pretty good explanation about i18n found at http://en.wikipedia.org/wiki/Internationalization after the meeting, but I don't believe they will read it carefully, anyway, it's well written:
Methods

The current prevailing practice is for applications to place text in resource strings which are loaded during program execution as needed. These strings, stored in resource files, are relatively easy to translate. Programs are often built to reference resource libraries depending on the selected locale data. Thus to get an application to support multiple languages one would design the application to select the relevant language resource file at runtime. Resource files are translated to the required languages.
This method tends to be application-specific and at best, vendor-specific. The code required to manage date entry verification and many other locale-sensitive data types also must support differing locale requirements. Modern development systems and operating systems include sophisticated libraries for international support of these types. However many development environments still lack full Unicode support, which drastically hampers the translation effort, especially to East Asian languages.
pageicon Tuesday Jun 14, 2005

Look at i18n from l10n's point of view


If you are reading this blog, I believe you know what's i18n and l10n :-), and we all know there are many many similar or different definitions of i18n and even l10n everywhere, in books, on websites, blogs, etc. I'm not going to repeat any of those definitions here but instead, I'd like to try to talk about i18n from l10n's point of view because I have been working on l10n for over 15 years ;-)

From my experiences or understanding, i18n of software has two kinds of customers or users (btw, I bet you know the difference between customers and users, customers mean those who pay you money, it doesn't matter whether they really use your products or not, users might just use your product without paying you for whatever reason ;-):
  1. External or final users who use the i18n features of a software product to handle their native languages.
  2. Internal l10n team who provide language specific features based on the i18n framework of your product before it's released.
 What I'd like to write next time will be mainly about how this internal l10n team look at i18n.

I18n vs L10n

Hello, This is my first weblog, I hope to write some interesting things about i18n and l10n, their definitions, differences, relationship, dependences, conflicts,etc. Brian.

« December 2009
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today

Feeds

Search this blog

Links

Weblog menu

Today's referrers

Today's Page Hits: 121