[Libreoffice-qa] Moztrap, some questions

Hi all, Yifan,

So after a long time (sorry for this long absence), I would like to come
back to Moztrap and try to help to test it.
My first question, the most important for us, is there now a possibility
of localization for :
- the tests
- the environment
 From what I see on the todo list Yifan has written long ago the point :
  5. Look into i18n and l10n of Moztrap, we need translation system for
both test cases and Moztrap UI.
Does it mean that it's possible, or does it mean it's not yet possible
or that we need to find/define a translation process?

My second question: is there a possibility to store sample documents on
Moztrap.

Thanks in advance
Kind regards
Sophie.

--
Sophie Gautier <[hidden email]>
Tel:+33683901545
Membership & Certification Committee Member - Co-founder
The Document Foundation
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi Sophie,

On Mon, Aug 13, 2012 at 11:14:34AM +0200, Sophie Gautier wrote:
> Hi all, Yifan,
>
> So after a long time (sorry for this long absence), I would like to
> come back to Moztrap and try to help to test it.

Welcome back :) Please let me know if you got problem of registration.

> My first question, the most important for us, is there now a
> possibility of localization for :
> - the tests
> - the environment
> From what I see on the todo list Yifan has written long ago the point :
>  5. Look into i18n and l10n of Moztrap, we need translation system
> for both test cases and Moztrap UI.
> Does it mean that it's possible, or does it mean it's not yet
> possible or that we need to find/define a translation process?

I ever had a talk with the Moztrap developers and it seems neither of the
localization plans has been on the rador yet :( It needs some deep hacking of
the code if we want to do that particularly to Libreoffice. So it is not easy
to handle the localization in Moztrap yet.

One way to workaround is to mix localized wording of test cases into the
existing English ones, as what we did for Litmus. But it is rather time
consuming to translate and maintain, because Moztrap split test cases into
steps. With this method, we need to *manually* maintain translation for each
test steps and their corresponding expected results. Besides, for some of the
test cases, localized version might not share exact steps with the English
version. So I did not put anything localized to the Moztrap test case base
yet.

I feel it is possibly better to maintain translation version of test cases in
a different data set, either by hacking the existing Moztrap database or
putting the translation for test cases to somewhere else like wiki, then
manually put the link back to Moztrap original English test case.

Any way, we currently really need more people to get involved, try Moztrap,
make contribution and share ideas :)

One question is can we termporarily survive with pure English wording test
cases, though they are allowed to choose running under any localizations?

> My second question: is there a possibility to store sample documents
> on Moztrap.

Yes, one of the moztrap's nice feature is attachement support per test case :)



--
  Yifan Jiang
  Libreoffice / SuSE
  Contact: yifan - irc.freenode.net/libreoffice
  =============================================  
  http://www.libreoffice.org/
  http://www.documentfoundation.org/

_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi Yifan,

On 13/08/2012 12:08, Yifan Jiang wrote:
I didn't replied yesterday because I wanted to think more about it. I
feel that investing work (and you already have invested a good amount of
work on it) in a tool dedicated to tests for average users in the
language communities that is not localizable (or with lot of
difficulties) is a waste of time. We will miss our goal and take the
risk to provide one more tool (after Litmus) that is not suitable to the
people wanting to contribute and will discourage them.
>
>> My second question: is there a possibility to store sample documents
>> on Moztrap.
>
> Yes, one of the moztrap's nice feature is attachement support per test case :)

that's a good point, but unfortunately less important that localization.
Thanks for your quick answer, I will continue to seek a solution for
these manual tests in all languages.

Kind regards
Sophie
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi Sophie,

I agree with your point that the localization is important, while the function
and working process a tool is able to provide is also critical to meet our
goal, isn't it? :) Moztrap takes more advantage in the latter and it has an
activated development team. That's why I still believe it is worthy a bit of
thinking how to workaround the l10n solution in Moztrap.

If you are doing some research for some other tools or methods, I'll certainly
be here to support when a potential better tool or method appears in front of
us :)

Let me go back a bit to Moztrap. As I ever mentioned two types of localization
need to be concern:

    1. UI localization of Moztrap buttons, navigators etc.

    2. Test case l10n that allows people to translate existing test cases,
    according to with testers will be able to understand them.

The 1st point tightly depends on upstream framework update, I might be able to
help out to implement it in future if we reach common sense with upstream. But
it seems less important than the second one, I remember we used Litmus either
without this before?

I guess the 2nd point is more emergent in our situation since the content of
test cases should be standing understandable and suitable for language
specific function coverage. Then people can immediately start to test without
knowing much English. Noticed from the last mail, 2 workarounds come to my
mind:

    1. we do similar things what we did in Litmus that put all language
    versions test case into a single one by mixed manner.

    2. translate the test case in wiki and give the link back to Moztrap

Now I am expanding more about the first workaround. Through the split "Step"
concept in Moztrap together with a nice feature I just found that test case
steps/expected pair is "Markdown" syntax supported
(http://daringfireball.net/projects/markdown/syntax#list), a new
idea comes to my mind that it is possible we use the "Steps" to distinguish
various language version of a test case. Here is what it possibly looks like
the demo:

    http://vm12.documentfoundation.org/runtests/run/21/env/631/

Concretely, for one particular language, we may put a real life test case
steps and expected results into one single row of Moztrap step/expected
box. Each Moztrap step would represent a full description of the detailed test
content in one language.

For creating a readable format of each steps, we can use pretty simple
Markdown language. Basically the content in the demo was populated in the text
(with a bit markdown rules) as:

-------------------------------><--------------------------------------------
Test that creating a new database - case 1

    When in English
    ===============
    * launch Libreoffice Base (vp1)
    * enter a name for the database in the dialog box and click OK (vp4)
    Then in English
    ===============
    1. the database application appears, the database wizard opens
    2. the dialog for "save and proceed" appears

    When in French
    ==============
    * lancement LibreOffice Base (vp1)
    * cochez la case [Créer une base de données], puis cliquez sur le bouton Suivant. (vp2)
    Then in French
    ==============
    1. l'application de base de données apparaît, l'assistant base de données s'ouvre
    2. la boîte de dialogue pour "sauvegarder et passer" apparaît

Test that creating a new database - case 2

    When in English
    ===============
    ..
   
    Then in English
    ===============
    ..

    When in French
    ==============
    ..
   
    Then in French
    ==============
    ..
-------------------------------><--------------------------------------------

In addition, for more concept of Moztrap, the official manual is helpful:

    http://moztrap.readthedocs.org/en/1.0.X/userguide/index.html

Also I am on my way updating Moztrap wiki pages this week:

    https://wiki.documentfoundation.org/Moztrap
    https://wiki.documentfoundation.org/Moztrap/Moztrap_User_Guide

Would you let me know how do you think about these?

Best wishes,
Yifan

On Tue, Aug 14, 2012 at 02:55:31PM +0200, Sophie Gautier wrote:
--
  Yifan Jiang
  Libreoffice / SuSE
  Contact: yifan - irc.freenode.net/libreoffice
  ============================================= 
  http://www.libreoffice.org/
  http://www.documentfoundation.org/



_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi Yifan,

it is great that you found time to work on Moztrap again.

Yi Fan Jiang píše v St 15. 08. 2012 v 00:46 -0600:
> Let me go back a bit to Moztrap. As I ever mentioned two types of
> localization need to be concern:
>
>     1. UI localization of Moztrap buttons, navigators etc.
>
>     2. Test case l10n that allows people to translate existing test
> cases,
>     according to with testers will be able to understand them.

> The 1st point tightly depends on upstream framework update. It seems
> less important than the second one, I remember we used Litmus either
> without this before?

Yes, the UI localization is slightly less important because people do
the same actions over and over. We could describe it in the wiki.


> I guess the 2nd point is more emergent in our situation since the
> content of test cases should be standing understandable and suitable
> for language specific function coverage. Then people can immediately
> start to test without knowing much English.

yup

>  Noticed from the last mail, 2 workarounds come to my
> mind:
>
>     1. we do similar things what we did in Litmus that put all
>  language versions test case into a single one by mixed manner.

I like this because people see the translation out of box.

>     2. translate the test case in wiki and give the link back to
> Moztrap

I am afraid that it would be hard to maintain and too much clicking.


> it is possible we use the "Steps" to distinguish various language
> version of a test case. Here is what it possibly looks like the demo:
>
>     http://vm12.documentfoundation.org/runtests/run/21/env/631/

Hmm, the advantage is that you see everything in one place. The steps
are compact for one language.

The pity thing is that it does not use the nice Moztrap feature where
you see "Step" and "Expected Results" next to each other.

I wonder how it would look if we translate the steps, results inside
each box. I mean to a syntax like:

Step1:                                Result:
[en] launch Libreoffice Base          [en] the database application
                                           the database wizard opens
[fr] lancement LibreOffice Base       [fr] l'application de base de
                                           données apparaît, l'assistant
                                           base de données s'ouvre

Step2:
[en] enter a name for the database    [en] the dialog for "save and
     in the dialog box and click OK        proceed" appears
[fr] cochez la case [Créer une base   [fr] la boîte de dialogue pour
     de données], puis cliquez sur         "sauvegarder et passer"
     le bouton Suivant.                    apparaît


Of course, it will be harder to follow the steps because the description
will be longer but it should not be that bad. I think that we will have
only few translations in the beginning. I hope that Moztrap could
support translating relatively soon.


The big advantage is that it keeps the translations in sync with the
English original. Also it uses the "step/result" Moztrap feature => It
will be much easier to move the test cases into newer Moztrap that might
support translations. We will not need to rewrite the test cases during
such migration. Easy script will be enough to save the translations into
the right place.

Of course, this is only mine opinion. I wonder what say others that will
use Mozrap.

Best Regards,
Petr

_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi,

On Wed, Aug 15, 2012 at 12:44:07PM +0200, Petr Mladek wrote:
> >     2. translate the test case in wiki and give the link back to
> > Moztrap
>
> I am afraid that it would be hard to maintain and too much clicking.

Maybe we could add a link to the page itself on google translate? For
understanding the testcase it should be good enough (if not we extend the
original description, which helps the english and the localized community?)

I fear manually translated testcases are doomed to fail as they will always be
outdated/incomplete during the timeframe that matters. Using automatic
translation (and tweaking the original so it comes out understandable) might
work though. Automatic translation is by now mostly only a problem, if you dont
control the source.

Best,

Bjoern
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi Petr, Yifan, all
On 15/08/2012 12:44, Petr Mladek wrote:
and that explains why we met so little success with Litmus.
>
> Yes, the UI localization is slightly less important because people do
> the same actions over and over. We could describe it in the wiki.

If you want to attract people from the overall community, UI is as
important as the translation process of the tests. The more the task is
complicated or not attractive, the more we lose people interest. Even
the FR community which was quite motivated for these tests has resigned now.
And even some experienced users don't speak English or do not want to
contribute in an English environment. It's also important to show to our
language communities that we try to answer to their needs. In my point
of view, it's not only about the tests, but also how we are able to
gather people around that tool.
That was what we had in the TCM and was very easy for the tester to
understand what was asked and the expected result at the same time and
it helps also to adjust/adapt the translation.
We need to keep in mind that a large part of the users of this tool will
make their first steps in QA and that it is most of the time a first
door for them to contribute to our community.
I don't know if you have ever used the TCM, the requests that was listed
first to enhance it was l10n of the UI and the usability for first time
contributors. Hence why I'm focusing on these points :) based on the
experience of Litmus vs TCM contributors.

Kind regards
Sophie
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi Bjoern,
On 15/08/2012 13:00, Bjoern Michaelsen wrote:
Imho, that won't work for two reasons:
- behavior is not the same in every language and testing may differ/be
adapted depending on the local
- UI strings are not the same due to localization, and we are also QAing
our l10n when we do those tests in our language

Kind regards
Sophie
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

On Wed, Aug 15, 2012 at 02:29:53PM +0200, Sophie Gautier wrote:
> Imho, that won't work for two reasons:
> - behavior is not the same in every language and testing may
> differ/be adapted depending on the local

In that case it is even more important that the testcase describe _all_ the
information for _all_ locales, otherwise there will be a terrible mess with
conflicting feedback (e.g. english testers reporting its fine, french reporter
reporting it is broken, both thinking they are testing the same thing).

Such a testcase _must_ contain the whole behaviour for all locales, e.g.:

1) Open libreoffice
Note: In the low german localization, you are required to mumble "Moin" while
doing that.

> - UI strings are not the same due to localization, and we are also
> QAing our l10n when we do those tests in our language

Thats also easily amended/clarified in cases were the autotranslation does fail.
Also I dont think we want to hardcode the expected translations in the
testcases -- that makes no sense at all (as that hardcoding is just as likely,
if not more so, to be wrong or outdated as the product).

Best,

Bjoern
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi Bjoern,
  15/08/2012 15:20, Bjoern Michaelsen wrote:
it's not necessary, the people from the team who reports a misbehavior
is aware of the difference between EN and his language. This is one of
the first thing you check when you are testing a local environment,
you've got it in both language every time. And for example, I don't care
how it behaves in German or when using CJK, etc. If it happens that
there is a real strange thing, we speak together with the other language
teams (the reason of the request for a dedicated list) and try to sort
out a real bug or a problem with the test, just as we do with l10n.
>
>> - UI strings are not the same due to localization, and we are also
>> QAing our l10n when we do those tests in our language
>
> Thats also easily amended/clarified in cases were the autotranslation does fail.
> Also I dont think we want to hardcode the expected translations in the
> testcases -- that makes no sense at all (as that hardcoding is just as likely,
> if not more so, to be wrong or outdated as the product).

Checking/understanding the google autotranslation takes more time than
doing it straight ;)

Kind regards
Sophie
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

On Wed, Aug 15, 2012 at 04:29:10PM +0200, Sophie Gautier wrote:
> it's not necessary, the people from the team who reports a
> misbehavior is aware of the difference between EN and his language.
> This is one of the first thing you check when you are testing a
> local environment, you've got it in both language every time.

Thats a rather dangerous assumption as it severely raises the barrier to entry.
Documenting such differences by having texts that say slightly different things
in different languages is a horrible idea.

Best,

Bjoern
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

On 15/08/2012 17:31, Bjoern Michaelsen wrote:
> On Wed, Aug 15, 2012 at 04:29:10PM +0200, Sophie Gautier wrote:
>> it's not necessary, the people from the team who reports a
>> misbehavior is aware of the difference between EN and his language.
>> This is one of the first thing you check when you are testing a
>> local environment, you've got it in both language every time.
>
> Thats a rather dangerous assumption as it severely raises the barrier to entry.
> Documenting such differences by having texts that say slightly different things
> in different languages is a horrible idea.

Beside the facts that we worked that way for years, if you don't trust
the people managing the tests and the team, Litmus/Moztrap is useless,
as they will be the only persons able to understand the test results
(and the remarks of testers) and compare them to BZ anyway. There is a
process and an organization where the tool is only a database for us
(but without it we can't do anything unfortunately).
Kind regards
Sophie
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi,

On Wed, Aug 15, 2012 at 06:27:59PM +0200, Sophie Gautier wrote:
> Beside the facts that we worked that way for years,

That does not mean we shouldnt improve on it.

> if you don't trust the people managing the tests and the team,

Thats a strawman argument: I never said or implied that. I said that it will
severly raise the barrier to entry (and we need to keep that as low as possible
so that this can take off).

Can we keep the discussion constructive?

Best,

Bjoern
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Sophie Gautier píše v St 15. 08. 2012 v 14:29 +0200:
We had this discussion on Litmus times. We need to split the test cases
into language independent and language specific groups. I think that
most functionality is language independent and thus simple translation
of the test case should be enough. The few language-specific test cases
might need special handling.

I think that we have to extend Moztrap to translate test cases and UI
sooner or later. We need to find a temporary solution that will allow
testers to work with it already now and allow to migrate the test cases
to the translated framework later easily.

> - UI strings are not the same due to localization, and we are also QAing
> our l10n when we do those tests in our language

I also think that we will get better results with our own localization.
Most test cases should stay the same between few releases. I think that
we could survive one or two years with inline translations. I hope that
we could get real localization support within that timeframe.

We are going to pay some external developers to improve bugzilla this
year. I would imagine that we could get some money to improve Moztrap
next year if we were not able to do it using our resources.


Best Regards,
Petr

_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi all,

Thanks all your concern of future Moztrap!

On Wed, Aug 15, 2012 at 08:00:37PM +0200, Petr Mladek wrote:
Hi Bjoern,

  It actually is a brilliant idea to make all the stuff automatically synced, but in
  practice it needs a lot of time to investigate and manual interference seems
  inevitable. I am sharing my concern that we need to make Moztrap *fastly*
  adapted to all QA people with very limited resource. And for sure we should
  consider how the test case should currently organized for migrating to a future
  better solution (how automation translation plays a role here could be one of the options).

  What enlightens me that it should make sense to leverage automation
  translation technique in Moztrap UI translation :)
 
> We had this discussion on Litmus times. We need to split the test cases
> into language independent and language specific groups. I think that
> most functionality is language independent and thus simple translation
> of the test case should be enough.
>
> The few language-specific test cases might need special handling.

Hi All,

  Yes, this was the assumption.

  For a language independent case, I tend to believe English version of it is
  *must-to-have*, and all direct translation of test cases in different
  languages is *prefer-to-have*.

  For those language dependent test cases (only makes sense to test in French
  locale for example), it makes sense to write in native language only. While an
  English translation for it is still *better-to-have* since we want to share
  information in the community. At least English speaking people could
  understand what has been tested when reviewing and reusing the test.

  In either of the case, it will not seem to break a workaround like:

      http://vm12.documentfoundation.org/runtests/run/21/env/633/
      or
      http://vm12.documentfoundation.org/runtests/run/23/env/634/

  Just wonder how do them look like to you?

I am for it.

> We are going to pay some external developers to improve bugzilla this
> year. I would imagine that we could get some money to improve Moztrap
> next year if we were not able to do it using our resources.

This is cheerful :)

--
  Yifan Jiang
  Libreoffice / SuSE
  Contact: yifan - irc.freenode.net/libreoffice
  =============================================  
  http://www.libreoffice.org/
  http://www.documentfoundation.org/


_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Yi Fan Jiang píše v Čt 16. 08. 2012 v 01:31 -0600:
>   It actually is a brilliant idea to make all the stuff automatically synced, but in
>   practice it needs a lot of time to investigate and manual interference seems
>   inevitable. I am sharing my concern that we need to make Moztrap *fastly*
>   adapted to all QA people with very limited resource. And for sure we should
>   consider how the test case should currently organized for migrating to a future
>   better solution (how automation translation plays a role here could be one of the options).
>
>   What enlightens me that it should make sense to leverage automation
>   translation technique in Moztrap UI translation :)

On one side, I like the idea of automatic translations. Though, I am
afraid that we will need real localizations support in Moztrap anyway
because:

        + better translations quality; tests need to be understandable
          even for beginners
        + language dependent tests; they can't be translated directly
        + support more languages; Google is powerful but the translator
          supports less localizations than LO; also I am not sure of the
          quality of each language; I guess that some languages are
          easier to translate automatically than others

BTW: I think that there will be similar problems with automatic
translations and real translations. You will need to modify UI and touch
similar piece of code for both of them.

I would prefer to spend resources on real localization than on the
automatic translation.

Note that we have many active translators. We currently do not have
enough hackers that would allow them to translate Moztrap.


>   For those language dependent test cases (only makes sense to test in French
>   locale for example), it makes sense to write in native language only. While an
>   English translation for it is still *better-to-have* since we want to share
>   information in the community. At least English speaking people could
>   understand what has been tested when reviewing and reusing the test.

Also I think that many language dependent tests will have the same
principle and number of steps. For example, spell checking is tested the
same way in all localizations. You just need to use another test text
and expect another broken words, another suggested replacements, ...


>   In either of the case, it will not seem to break a workaround like:
>
>       http://vm12.documentfoundation.org/runtests/run/21/env/633/

+ advantages:
        + compact; do not need to scroll that much
+ disadvantages:
        + steps and expected results are far from each other; it is
          harder so see how exactly they are connected

A solution would be to use another syntax, e.g.

When in English
  1. launch Libreoffice Base
      >> the database application appears, the database wizard opens
  2. check [Create a database] then click on Next button.
      >> the dialog for "save and proceed" appears
  3. check [Yes, register the database for me] and [Open the database
     for edition] and click on Finish
      >> a file save dialog appear
  4. enter a name for the database in the dialog box and click OK
      >> a new database can be created successfully

When in French
  1. ...
      >> ...
  2. ...


>       http://vm12.documentfoundation.org/runtests/run/23/env/634/

+ advantages:
        + step and result is clearly connected; this connection is
          enforced by UI when creating the test
        + follows the current design => it is more intuitive when
          creating the test case; also it should be easier to switch
          to real localization once implemented
+ disadvantages:
        + harder to find your localization for each step

Well, the brain automatically finds some known words. Also I think that
we will get only very few localizations in the beginning; I hope that we
will get real localizations support before it gets unreadable.


Best Regards,
Petr

_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi,

On Thu, Aug 16, 2012 at 02:35:49PM +0200, Petr Mladek wrote:
Still the timing is critical here -- blocking on translations in the
beta-frenzy is not an option and the time windos is rather tight. What could
be done though is doing both: Using manual translation and priming it with an
automatic translation that than can be improved upon by an manual one. However
even then there are lots of issues with translations: The (english) source text
might change (because of an UI cleanup), making the localized version needing
an update (or at least an 'this is outdated' marker). That was one of the
reasons, why I like and suggested automatic translation as it changes with the
source text.
Doing manual translations, you will need the source and the translations text
to be under some form of version control. Possible, but a lot of work.

Best,

Bjoern
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: [hidden email]
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Hi.
tl;dr, but IMHO ideal localized MozTrap system could be designed this way:
Tests should be written using some kind of special text editor with autocomplete, in generic language (or based on English) using UI strings and then those strings substituted to the language of choice (not only French). The framework should be using .po files only.  How to achieve this? I don't know. Maybe integrate with Pootle server or sync with LO sources? This would allow to present UI strings in any language supported by LibreOffice. All this seems like good candidate for GSOC project...
My 2 eurocents.
Best regards.
P.S.
Having multilanguage MozTrap can lead us to multilanguage reports in Bugzilla... We do not want multilanguage Bugzilla, don't we? I already have to use translator services in reports submitted by French or Spanish people. Good to learn new languages, but... you know... time consuming while bugs triage.