[Chandler-dev] Re: This weeks progress in i18n of Chandler

[Markku Mielityinen]

Hi Brian,
> Hi Markku,
> I have opened bug 5952 for the functional tests and unit tests.
OK.
> You were added to review the patch I posted.
OK.
> In addition to working on the func tests I also updated all the unit 
> tests and did some i18n patching in other places as needed.
>
> This also exposed a bug in PyLucene indexing.
>
> Here are my comments on your functional tests updates:
>
> 1. The i18n_char logic you added only worked for the entire functional 
> test suite and broke individual tests.
>    The Functional tests can either be run as group or as individual 
> tests. Since you initialize i18n_char in FunctionalTestSuite.py
>     this broke the ability to run individual tests.
>
> 2. Using the i18n_char explicitly did not seem like the best choice to 
> me for a few reasons. First, it is fixed. Since it is a variable and
>    not a function once the i18n_char value is set it can not be 
> changed with out re-running the test. Second, the syntax to use it 
> requires a
>    lot of typing and is error prone:   u"%sSomeText%s" % (i18n_char, 
> i18n_char).
>
>     But I did like your idea of having a group of Unicode characters 
> to test against. So what I ended up doing was creating a method in 
> i18n.utils called addUnicodeWrapper. And added a shortcut uw. So one 
> can simply do this:
>
> from i18n.utils import uw
>
> uw("Some text")
>
> This method employs the same basic approach as your i18n_char logic. 
> But has a few advantages. First, it is a method call and not a 
> variable which means additional or alternate logic can be added to the 
> method without altering any code that calls the method.
> Second, having a method gave the flexibility to return different 
> values. I created an array of your i18n_char seeds and added some more
> Unicode characters to the array. On each call to uw two Unicode 
> characters are chosen from the array at random for the beginning and 
> ending position of the string. Once a value is returned by uw it is 
> cached so any addition calls will return the same value. This is 
> important since many tests use comparison as a means of validation.
>
> 3. Some of the tests were not updated to compare the new values. 
> TestImportOverwrite.py for example was looking for the original values 
> before you added the i18n_char wrapper causing it to fail. The 
> TestCreateAccounts.py had a similar problem. The name of the account 
> was the old version i.e. "Personal SMTP" != u"%sPersonal SMTP%s" % 
> (i18n_char, i18n_char).
>
> 4. The Arabic Unicode string you used contained a space at the 
> beginning and end. This caused unexpected issues as the Arabic 
> character is rendered right to left in some of the wx UI.  Many 
> comparison tests failed cause of the additional space plus the right 
> to left nature of Arabic. This was a subtle bug that took me a while 
> to track down.
>
> Overall I liked what you did on the Functional Test improvements.
I have an idea how to make it even better but more about that next week. 
I think that your improvements were good as well :)
> How is the xrc i18n updating going?
I have asked bear to prepare the makefile target, see bug Bug 5951, but 
otherwise it is on hold until we can get a few other things sorted out. 
The good news is that I now have an idea how we should do this and after 
that the implementation usually does not take that long.

Cheers,
    Markku