Ubuntu Wiki

• Launchpad Entry: qa-m-mago-i18n

• Created:

• Contributors: jtatum, apulido

• Packages affected: mago

Summary

Mago works only with "C" locale applications. We need to modify it in order to make it work with different locales.

Release Note

We have changed the way we write Mago tests in order to be able to write tests in different locales. Please, refer to the Mago documentation to see how to write international tests.

We tried to make sure that backwards compatibility is there, but, if your test broke, please, file a bug against the Mago project.

Rationale

There are some local Ubuntu derivatives that are willing to test their systems using Mago. Right now, Mago architecture, only allows testing applications in English.

We should make possible to do this, as we could all benefit with the new tests coming from derivatives.

User stories

• Juanje, based in Andalusia (Spain), wants to use Mago to test a Spanish Ubuntu derivative. He is not able, as Mago only works for locale "C".

Assumptions

Design

Current situation

Currently there are two problems that prevent testing localized applications:

• First, Mago forces the application to start always in locale "C". This is easy to fix.
• Second, Mago uses English strings to discover applications. This is the big change needed.

Future

We will allow Mago to run applications in any locale. Also, we will separate the discovery of applications, from the locale. To do that, we need to create a separation between text and test code.

The test code won't have any reference to application text, which will be in a separated layer.

We will include a scripted way to generate testing strings based on POT files. Once generated, these files will be in the test code (not the applications) and they will be maintained by the testers. We cannot generate them at run time, as, in that case, we won't catch up regressions on not translated strings.

Mago will have a library to connect those strings with the test code.

Implementation

Code Changes

• When launching applications, we should avoid forcing locale "C". (easy fix)
• A new script will be created to generate strings for a given application. This should be integrated in the "mago" package somehow (with an option to "mago" or a different binary).
• The "mago" command will have an option to run the test in a specific locale.
• All the English strings will be moved to separate text files.
• A library will be written to access those strings from the test code.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Agenda

• Introduction
• Things to change in the framework
• How to represent locale in the tests

Using gettext is the right

• We need to get rid of the constants that holds the strings

If we get LDTP to use the widget id, instead of the translated string, we could reuse the tests easier

In fact this is not the greatest idea

To start with something, we could make the test run (and work) in every language.

Having a baseline of strings autogenerated, but having them controlled within the tests

Actions

• Create a mago branch for the i18n work (ara)
• Move English strings out of mago (ara)
• Introduce a way to get the strings from the text files (ara, jtatum)
• Create a script to generate the first baseline of strings (jtatum)
• Update the documentation (ara)

CategorySpec