Rusty, I read your test about the i18n support.
I think it is not complete test method.
Your method is just cover the string replacement. But we cannot test if the application can set language based on current domain environment.
when testing, we need to change our test environment to other language. And then, we can use the related .mo file and launch applications to check if the interpretation is OK.
For general applications, the method using i18n and l10n are:
1) in application initialization codes, programmer should call API to get current language environment and set domain according env (like setlocale, bindtextdomain in C)
2) in other application codes, programmer should call macro to invoke all the strings/time/number-format... which he want to interpret.
the above steps should be called as internationalization.
3) when finish application programming, programmer should create .po and .mo files based on the app source codes with gettext tool
Rusty, I read your test about the i18n support.
I think it is not complete test method.
Your method is just cover the string replacement. But we cannot test if the application can set language based on current domain environment.
when testing, we need to change our test environment to other language. And then, we can use the related .mo file and launch applications to check if the interpretation is OK.
For general applications, the method using i18n and l10n are: time/number- format. .. which he want to interpret. ation.
1) in application initialization codes, programmer should call API to get current language environment and set domain according env (like setlocale, bindtextdomain in C)
2) in other application codes, programmer should call macro to invoke all the strings/
the above steps should be called as internationaliz
3) when finish application programming, programmer should create .po and .mo files based on the app source codes with gettext tool