Forum Discussion

lishadaniel's avatar
lishadaniel
New Contributor
7 years ago

Multilingual Testing in Desktop Application using TestComplete

Hi,

 

I have to test a desktop application that runs in 11 different languages (French, Japanese etc).

 

I have refereed the below link for Solution:

https://community.smartbear.com/t5/TestComplete-Functional-Web/Use-automated-script-to-test-the-software-which-supports/m-p/91815#M22853

 

Tried solutions:

1. Tried Name Mapping Configuration Option : But maintaining it for 11 languages seems difficult.

2. Tried to map a unique property like Screenleft, Screentop etc as mentioned in the above solution. When the application is moved from one position to another in the screen, these values are again varying. Hence script is failing. 

 

The tested app does not have any unique ID as it is changing dynamically.

 

Could anyone suggest a solution for this issue? :(

 

 

 

 

 

 

  • JuliaBernikova's avatar
    JuliaBernikova
    SmartBear Alumni (Retired)
    7 years ago

    Hi,

     

    Unfortunately, if the problematic objects have no unique properties apart from the text (which changes with the language), the only way to use Name Mapping is to create different configurations. Or, you can use Conditional Mapping ("some text in French" OR "some text in Japanese" OR etc.), but it'll take just the same amount of time to configure.

     

    Just to be sure there are no unique properties/other workarounds to the issue, you can submit a support case, we'll investigate the issue in more detail.

     

    By the way, we don't usually recommend using properties like ScreenLeft, ScreenTop etc. - this way, you basically switch to coordinate-based testing which is not very reliable.

  • Bonibom's avatar
    Bonibom
    Contributor
    7 years ago

    I can share my solution of a similar problem.

     

    1. Created a sqlite database containing a table containing localized control captions

    Example:

    ID                                                 EN                  RU                     

    IDS_MAIN_WND_CAPTION   Application     Приложение

    and so on    

    2. AUT creates registry value corresponding currently selected localization when it is being installed (for example, REG_SZ Language=DE, FR, JA and so on)

    3. Custom created entity (class LanguageProvider) reads registry value data and then obtains a control caption (by ID from the database)  corresponding currently selected localization from the database column. Connection string will be very easy

    Example:

con_str = '''SELECT {} FROM L10N WHERE SOURCE = {}'''.format("FR", "IDS_MAIN_WND_CAPTION")

    4. Obtained value is transferred to FindChildEx (WaitWindows etc.) function 

    5. Tests "know" what a language is selected (as localization is being selected whether by UI control or defining command line parameter) 

     

    Benefits of this approach:

    1. You can add support as many localizations as you need. Only thing you will need is to add a new column to the database (for example, CN) and create CN control captions for each string ID. String IDs will not be changed and selection from the database will always correspond to the localization stated in a test.

    2. You do not need to modify your tests or high level UI wrapper under AUT as if a control caption is changed you only need to modify corresponding value of string ID in the database.

     

    This requires additional scripting but not so much as, for example, interaction with sqlite database can be performed by using standard python package sqlite3.

    But this is very flexible. 

  • lishadaniel's avatar
    lishadaniel
    New Contributor
    7 years ago

    Hi,

     

    I have to test a desktop application that runs in 11 different languages (French, Japanese etc).

     

    I have referred the below link for Solution:

    https://community.smartbear.com/t5/TestComplete-Functional-Web/Namemapping-for-Multilingual-testing/m-p/66467#M6915

     

    Tried solutions:

    1. Tried Name Mapping Configuration Option : But maintaining it for 11 languages seems difficult.

    2. Tried to map a unique property like Screen-left, Screen-top etc as mentioned in the above solution. When the application is moved from one position to another in the screen, these values are again varying. Hence script is failing. 

     

    The tested app does not have a unique ID as it is changing dynamically.

     

    Could anyone suggest a solution for this issue? :(

     

     

     

     

     

     

    • AlexKaras's avatar
      AlexKaras
      Champion Level 3
      7 years ago

      Hi,

       

      Basically, you have only two options:

      a) It is possible to identify/find required UI elements of the tested application using properties that do not depend on the language (e.g. by the id property that keeps the same unique value for any language);

      b) The only way to find/distinguish between different UI elements is to use language-dependent properties (e.g. Caption).

       

      In case a) you are a lucky one as your test code does not depend on the language and you may use either NameMapping or .FindXXX() functionality (or their combination).

      In case b) you can use NameMapping Configurations or stick to .FindXXX(). I agree that maintaining a lot of configurations for NameMapping can be expensive and not practical for large complex application.

      To use .FindXXX() you will need to use language-specific values for the search properties. One of the possible approaches described here long ago (I don't have direct link, sorry) was to create a reference file in a form of a table. The first column of this table contains some unique identifier used in test code, all other columns contain localized text. You will have to create a helper function that will get an identifier and required language code and return localized text. This text will be used as a value for the .FindXXX() function.

      A side benefit of this design is that:

      a) It can be used for partially localized applications (e.g. if localized text is not found, base one (e.g. English) is returned);

      b) It can be used to verify that all tested UI elements are localized (e.g. post warning if some localized text is not found).

    • karkadil's avatar
      karkadil
      Valued Contributor
      7 years ago

      I would start from wondering, do you really need to support all 11 languages completely?

       

      Usually functionality does not depend on the application language. It is enough to test AUT functionality in one language, but you may have a couple tests for verifying language-specific cases (like switching from one language to another, making sure that keyboard shortcuts work the same way in all languages, etc.).

       

      So in this case you'll need to have one big NameMapping configuration for one language, all other configurations will be much smaller covering specific parts of the application.

       

      Also, take into account that NameMapping configurations do not solve all issues, you will still need to keep 11 versions of menu items (which are not mapped as other controls).