Ticket #158 (closed task: fixed)

Opened 3 years ago

Last modified 3 years ago

Proposed Test Day - l10n/i18n test day

Reported by: rhe Owned by: rhe
Priority: major Milestone: Fedora 15
Component: Test Day Version:
Keywords: Cc: igorsoares@…, petersen@…, tflink@…, tfujiwar@…
Blocked By: Blocking:

Description

As discussed with Igor, this test day will be hosted on 2011-03-03.

Igor, have you figured out which features/areas you want to target on? Do you plan to use the l10n template and specific test results page for it or the formatted wiki test day result page as before?

Thanks.

Change History

comment:1 Changed 3 years ago by aalam

I think we need separate i18n/l10n test days as target can be different. Even we can add more than 1 test day.

comment:2 Changed 3 years ago by adamwill

if you want to have multiple test days on similar topics, one approach to consider is adding the second test day on tuesday or wednesday in the same week. We only list thursdays as open slots in the schedule, but actually if you want to run two test days in one week, on tuesday and thursday or wednesday and thursday, that's no problem, and we can just edit the table to add in the tuesday. that way it keeps all the events close together.

comment:3 in reply to: ↑ description ; follow-ups: ↓ 4 ↓ 5 Changed 3 years ago by igor

I prefer to use the formatted wiki test day result page as before. I intend to keep the l10n template just as a guide for translation teams to know which modules need testing, but it also have to be updated.

I'd like to give a special attention this time for langpack installation. Mainly regarding langpacks for Firefox 4 and Libre Office. And we also should target font rendering and input methods as usual.

We have two different groups of i18n test cases: installation and desktop related ones. So I'd divide the test days into those two groups rather than into i18n and l10n. Testers will hit both i18n and l10n bugs while running the tests anyway, and sometimes depending of the bug will be hard to figure out if it is a i18n or l10n bug at the moment, what can be done by further bug triage.

Of course we can try another approach, but since we have an intersection between l10n and i18n I think we can use it in our favor.

comment:4 in reply to: ↑ 3 ; follow-up: ↓ 6 Changed 3 years ago by aalam

Replying to igor:

I prefer to use the formatted wiki test day result page as before. I intend to keep the l10n template just as a guide for translation teams to know which modules need testing, but it also have to be updated.

I'd like to give a special attention this time for langpack installation. Mainly regarding langpacks for Firefox 4 and Libre Office. And we also should target font rendering and input methods as usual.

Langpack is good idea to test. Libre office has separate packages, but firefox don't have separate. Also we can test Language group support, which is by default installed by fedora (yum groupinstall <LANGUAGE>-support).

for Rendering and Input, we can have 4 basic test groups:

  • pango - gedit/firefox
  • qt - kwrite
  • icu - libre office
  • input - ibus
  • Printing - (can be print to file only - ps/pdf/svg)

We have two different groups of i18n test cases: installation and desktop related ones. So I'd divide the test days into those two groups rather than into i18n and l10n. Testers will hit both i18n and l10n bugs while running the tests anyway, and sometimes depending of the bug will be hard to figure out if it is a i18n or l10n bug at the moment, what can be done by further bug triage.

installation and desktop can better idea than i18n/l10n grouping. Actually Rendering/Input/Font? Testing requires few applications (as above), while for Basic translated Desktop we can test all default installed application (with desktop) for a language.

Of course we can try another approach, but since we have an intersection between l10n and i18n I think we can use it in our favor.

Can we use hybrid (mixed) approach?

  • installation - i18n/l10n (Single)
  • Desktop - two separate
    • l10n (Translation of default installed application)
    • i18n (input/rendering/printing) with one (or two) from each rendering engine.

comment:5 in reply to: ↑ 3 Changed 3 years ago by rhe

Replying to igor:

I prefer to use the formatted wiki test day result page as before. I intend to keep the l10n template just as a guide for translation teams to know which modules need testing, but it also have to be updated.

Okay.

I'd like to give a special attention this time for langpack installation. Mainly regarding langpacks for Firefox 4 and Libre Office. And we also should target font rendering and input methods as usual.

I used to host a yum langpack test day with Jens:

https://fedoraproject.org/wiki/Test_Day:2010-02-25_YumLangpackPlugin

I've added them in the Category:I18n_desktop. Feel free to add/polish the cases in need.

We have two different groups of i18n test cases: installation and desktop related ones.

Yeah, I divided the test cases into these two categories. At that time, I was confused about i18n and l10n, so I named all as i18n cases, where the translation tests should belong to l10n. I can change them to category:i18n/l10n cases. AFAIK the existing cases related to l10n/i18n are:

comment:6 in reply to: ↑ 4 ; follow-ups: ↓ 7 ↓ 8 Changed 3 years ago by rhe

Replying to aalam:

Replying to igor:

I prefer to use the formatted wiki test day result page as before. I intend to keep the l10n template just as a guide for translation teams to know which modules need testing, but it also have to be updated.

I'd like to give a special attention this time for langpack installation. Mainly regarding langpacks for Firefox 4 and Libre Office. And we also should target font rendering and input methods as usual.

Langpack is good idea to test. Libre office has separate packages, but firefox don't have separate. Also we can test Language group support, which is by default installed by fedora (yum groupinstall <LANGUAGE>-support).

for Rendering and Input, we can have 4 basic test groups:

  • pango - gedit/firefox
  • qt - kwrite
  • icu - libre office
  • input - ibus
  • Printing - (can be print to file only - ps/pdf/svg)

We have two different groups of i18n test cases: installation and desktop related ones. So I'd divide the test days into those two groups rather than into i18n and l10n. Testers will hit both i18n and l10n bugs while running the tests anyway, and sometimes depending of the bug will be hard to figure out if it is a i18n or l10n bug at the moment, what can be done by further bug triage.

installation and desktop can better idea than i18n/l10n grouping. Actually Rendering/Input/Font? Testing requires few applications (as above), while for Basic translated Desktop we can test all default installed application (with desktop) for a language.

Of course we can try another approach, but since we have an intersection between l10n and i18n I think we can use it in our favor.

Can we use hybrid (mixed) approach?

  • installation - i18n/l10n (Single)
  • Desktop - two separate
    • l10n (Translation of default installed application)
    • i18n (input/rendering/printing) with one (or two) from each rendering engine.

Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop?

comment:7 in reply to: ↑ 6 ; follow-up: ↓ 9 Changed 3 years ago by aalam

Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop?

I think we need to use two days (Tuesday and Thursday or Wednesday and Thursday as Adam mentioned)

actually fedora translation deadline is 2011-03-15, we need to do translation testing after that (2011-03-17...). i18n part can be done before that.

comment:8 in reply to: ↑ 6 Changed 3 years ago by igor

Replying to rhe:

Replying to aalam:

Can we use hybrid (mixed) approach?

  • installation - i18n/l10n (Single)
  • Desktop - two separate
    • l10n (Translation of default installed application)
    • i18n (input/rendering/printing) with one (or two) from each rendering engine.

It seems pretty straightforward to me. We definitively can manage the test days using this approach.

Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop?

Although there are more things to be tested in comparison with the installation test day I think one day is enough for desktop. Since it includes different input methods used in many languages we might have people joining in different timezones. We also can include the langpack tests in the installation test day in order to balance the workload a little bit.

comment:9 in reply to: ↑ 7 ; follow-ups: ↓ 10 ↓ 11 Changed 3 years ago by igor

Replying to aalam:

Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop?

I think we need to use two days (Tuesday and Thursday or Wednesday and Thursday as Adam mentioned)

Do you mean two days for desktop testing?

actually fedora translation deadline is 2011-03-15, we need to do translation testing after that (2011-03-17...). i18n part can be done before that.

I see no problem in hosting translation testing after the string freeze and before the translation deadline. It looks like the optimal situation to me. It gives an opportunity for translators to do runtime checking. Otherwise, if they find a translation error after the translation deadline then maintainers could refuse to rebuild a package because of an error in a specific language or to change a string that will impact several languages, what could lead to translation rework after the deadline.

The downside is that we won't have all modules rebuilt with new translations until 2011-03-01. Anyway, we still have an open slot in 2011-03-17 but it is two close from translation deadline which might not give enough time for maintainers to rebuild their packages. I would suggest 2011-03-31 but I'm afraid it is too late in the release cycle.

comment:10 in reply to: ↑ 9 ; follow-up: ↓ 12 Changed 3 years ago by rhe

Replying to igor:

Replying to aalam:

Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop?

I think we need to use two days (Tuesday and Thursday or Wednesday and Thursday as Adam mentioned)

Do you mean two days for desktop testing?

Yeah, I have the same concern. Currently the schedule is:

http://fedoraproject.org/wiki/QA/Fedora_15_test_days

actually fedora translation deadline is 2011-03-15, we need to do translation testing after that (2011-03-17...). i18n part can be done before that.

I see no problem in hosting translation testing after the string freeze and before the translation deadline. It looks like the optimal situation to me. It gives an opportunity for translators to do runtime checking. Otherwise, if they find a translation error after the translation deadline then maintainers could refuse to rebuild a package because of an error in a specific language or to change a string that will impact several languages, what could lead to translation rework after the deadline.

The downside is that we won't have all modules rebuilt with new translations until 2011-03-01. Anyway, we still have an open slot in 2011-03-17 but it is two close from translation deadline which might not give enough time for maintainers to rebuild their packages. I would suggest 2011-03-31 but I'm afraid it is too late in the release cycle.

Well, I'm a bit confused. First, for the i18n/l10n translation tests, the images used for testing are Alpha RCs provided by rel-eng, right? If yes, according to the schedule[1], 'Compose Alpha Candidate' is on 02-17, and 'create Beta Test Compose' is on 03-15. Will the new translations be included in Alpha RCs?

For i18n/l10n desktop tests, Will specific live image be built? Or should Alpha RC live image be used and then doing a fully update? Is 2011-03-03 ready for it?

comment:11 in reply to: ↑ 9 Changed 3 years ago by aalam

Replying to igor:

Replying to aalam:

Installation tests can be hosted in one day, I've added Tuesday(2011-03-01) as installation test day like Adam suggested. How about the desktop part? If all of these are included, do you think one day is enough for desktop?

I think we need to use two days (Tuesday and Thursday or Wednesday and Thursday as Adam mentioned)

Do you mean two days for desktop testing?

yes, it can be helpful if we will do i18n (limited application set) and l10n (major applications in default desktop) Testing.

actually fedora translation deadline is 2011-03-15, we need to do translation testing after that (2011-03-17...). i18n part can be done before that.

I see no problem in hosting translation testing after the string freeze and before the translation deadline. It looks like the optimal situation to me. It gives an opportunity for translators to do runtime checking. Otherwise, if they find a translation error after the translation deadline then maintainers could refuse to rebuild a package because of an error in a specific language or to change a string that will impact several languages, what could lead to translation rework after the deadline.

The downside is that we won't have all modules rebuilt with new translations until 2011-03-01. Anyway, we still have an open slot in 2011-03-17 but it is two close from translation deadline which might not give enough time for maintainers to rebuild their packages. I would suggest 2011-03-31 but I'm afraid it is too late in the release cycle.

yes, there is risk. packages may not be rebuild and if we test on 2011-03-31 , we expect that only critical issues can be fixed for i18n/l10n (with Beta). (One thing can be helpful is Gnome 3, translators can check gnome 3 translation once before release (April 04 is last day for translation)).

If we are going to do before translation deadline and find bug for translation, then it may be fixed before by translator and not too useful to report translation bug. So after translation deadline can be optimal time.

comment:12 in reply to: ↑ 10 ; follow-ups: ↓ 13 ↓ 14 Changed 3 years ago by igor

Well, I'm a bit confused. First, for the i18n/l10n translation tests, the images used for testing are Alpha RCs provided by rel-eng, right? If yes, according to the schedule[1], 'Compose Alpha Candidate' is on 02-17, and 'create Beta Test Compose' is on 03-15. Will the new translations be included in Alpha RCs?

Right, but the new translations will only be included in Alpha RCs for those packages rebuilt by maintainers.

For i18n/l10n desktop tests, Will specific live image be built? Or should Alpha RC live image be used and then doing a fully update? Is 2011-03-03 ready for it?

It is better to use a specific image for the l10n desktop tests, but it will be ready only by 2011-03-04, which is the date of the rebuild. The translation schedule [1] suggests to do string reviews in built UI between 2011-03-07 and 2011-03-15, which still is before the translation deadline.

Taking that in consideration I suggest the following dates:

  • 2011-03-01: l10n/i18n Installation Test Day
  • 2011-03-03: i18n Desktop Test Day
  • 2011-03-08: l10n Desktop Test Day

I know that 2011-03-01 is before the deadline for packages rebuild but Anaconda is constantly rebuilt so I see no problem in hosting that day. 2011-03-03 is not affected by rebuild date since it is only for i18n testing. 2011-03-08 will be after the rebuild so translators can test both with an updated Alpha or with the specific live image for string review.

[1] http://poelstra.fedorapeople.org/schedules/f-15/f-15-trans-tasks.html

comment:13 in reply to: ↑ 12 Changed 3 years ago by aalam

Replying to igor:

Well, I'm a bit confused. First, for the i18n/l10n translation tests, the images used for testing are Alpha RCs provided by rel-eng, right? If yes, according to the schedule[1], 'Compose Alpha Candidate' is on 02-17, and 'create Beta Test Compose' is on 03-15. Will the new translations be included in Alpha RCs?

Right, but the new translations will only be included in Alpha RCs for those packages rebuilt by maintainers.

For i18n/l10n desktop tests, Will specific live image be built? Or should Alpha RC live image be used and then doing a fully update? Is 2011-03-03 ready for it?

It is better to use a specific image for the l10n desktop tests, but it will be ready only by 2011-03-04, which is the date of the rebuild. The translation schedule [1] suggests to do string reviews in built UI between 2011-03-07 and 2011-03-15, which still is before the translation deadline.

Taking that in consideration I suggest the following dates:

  • 2011-03-01: l10n/i18n Installation Test Day
  • 2011-03-03: i18n Desktop Test Day
  • 2011-03-08: l10n Desktop Test Day

I know that 2011-03-01 is before the deadline for packages rebuild but Anaconda is constantly rebuilt so I see no problem in hosting that day. 2011-03-03 is not affected by rebuild date since it is only for i18n testing. 2011-03-08 will be after the rebuild so translators can test both with an updated Alpha or with the specific live image for string review.

it looks good for me. Translators will get enough time to fix any issue before deadline.

comment:14 in reply to: ↑ 12 ; follow-up: ↓ 15 Changed 3 years ago by rhe

Replying to igor:

Well, I'm a bit confused. First, for the i18n/l10n translation tests, the images used for testing are Alpha RCs provided by rel-eng, right? If yes, according to the schedule[1], 'Compose Alpha Candidate' is on 02-17, and 'create Beta Test Compose' is on 03-15. Will the new translations be included in Alpha RCs?

Right, but the new translations will only be included in Alpha RCs for those packages rebuilt by maintainers.

For i18n/l10n desktop tests, Will specific live image be built? Or should Alpha RC live image be used and then doing a fully update? Is 2011-03-03 ready for it?

It is better to use a specific image for the l10n desktop tests, but it will be ready only by 2011-03-04, which is the date of the rebuild. The translation schedule [1] suggests to do string reviews in built UI between 2011-03-07 and 2011-03-15, which still is before the translation deadline.

Taking that in consideration I suggest the following dates:

  • 2011-03-01: l10n/i18n Installation Test Day
  • 2011-03-03: i18n Desktop Test Day
  • 2011-03-08: l10n Desktop Test Day

I know that 2011-03-01 is before the deadline for packages rebuild but Anaconda is constantly rebuilt so I see no problem in hosting that day. 2011-03-03 is not affected by rebuild date since it is only for i18n testing. 2011-03-08 will be after the rebuild so translators can test both with an updated Alpha or with the specific live image for string review.

[1] http://poelstra.fedorapeople.org/schedules/f-15/f-15-trans-tasks.html

Thanks for clarifying this. I've updated the schedule accordingly:

comment:15 in reply to: ↑ 14 ; follow-up: ↓ 16 Changed 3 years ago by igor

comment:16 in reply to: ↑ 15 ; follow-up: ↓ 17 Changed 3 years ago by aalam

Replying to igor:

Replying to rhe:

Thanks for clarifying this. I've updated the schedule accordingly:

Thank you! Since we have reached a consensus about the dates I'm doing a list of test cases we need to review.

So far we have:

Anything else to add here?

Rendering (pango/qt/icu - those may be language specific) and Printing Test cases we can add. Also I would like to know about Gnome packages, even people may not directly translating, but it is Major part of Desktop.

comment:17 in reply to: ↑ 16 Changed 3 years ago by igor

Replying to aalam:

Rendering (pango/qt/icu - those may be language specific) and Printing Test cases we can add. Also I would like to know about Gnome packages, even people may not directly translating, but it is Major part of Desktop.

In i18n installation test cases there are some post install procedures that are toolkit specific. We can move them to a separate test case in order to test pango/qt/icu rendering.

Testing GNOME translations might be tricky since they have their own schedule and procedures. I'd rather articulate this test along with upstream teams.

comment:18 follow-up: ↓ 19 Changed 3 years ago by igor

Continuing the work I started at FUDCon Tempe I have been updating our test cases for the upcoming test days. Here are some changes I made:

comment:19 in reply to: ↑ 18 ; follow-up: ↓ 20 Changed 3 years ago by rhe

Replying to igor:

Continuing the work I started at FUDCon Tempe I have been updating our test cases for the upcoming test days. Here are some changes I made:

  • Post install procedures were moved from Category:I18n_Installation to Category:I18n_Desktop

Thanks, I also put the Yum Langpack Test Cases to that category.

  • Explicit step for checking language extensions was added to i18n_browsers test case as well as different toolkit testing.
  • Add explicit step for testing LibreOffice? on both Langpack_PackageKit_Application and Langpack Yum Application test cases
  • Update Langpack test cases for using yum instead of downloading builds from koji manually

Great, it does improve a lot.

Agree, now it's already covered by QA:Langpack_Yum_Application

This test aims to check the login and native text on desktop is correctly displayed and translated. I didn't find any case including this. Can you point it out?

I guess you meant the QA:Testcase_ibus_input can replace it, right? QA:Testcase_ibus_input is more detailed, but hasn't been updated for a long time. Is there any step need be modified to adapt the F-15 test day?

BTW, I noticed QA:Testcase_i18n_default_fonts was created recently by Tagoh to check if fonts packages for your language is correctly installed by running a script. I think this is a good test. So we will use all the tests in Category:I18n_Installation including it to the i18n/l10n installation Test day?

comment:20 in reply to: ↑ 19 ; follow-up: ↓ 21 Changed 3 years ago by igor

  • Cc tflink@… added

Replying to rhe:

This test aims to check the login and native text on desktop is correctly displayed and translated. I didn't find any case including this. Can you point it out?

As far as I understand the test case https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application has basically the same scope.

If you find that i18n_font_desktop is still valuable I can revert the change, no problem.

I guess you meant the QA:Testcase_ibus_input can replace it, right? QA:Testcase_ibus_input is more detailed, but hasn't been updated for a long time. Is there any step need be modified to adapt the F-15 test day?

Exactly, the ibus test case is far more detailed and seems to be version agnostic. I would like an opinion from aalam on this as well.

BTW, I noticed QA:Testcase_i18n_default_fonts was created recently by Tagoh to check if fonts packages for your language is correctly installed by running a script. I think this is a good test. So we will use all the tests in Category:I18n_Installation including it to the i18n/l10n installation Test day?

It's definitely a good test to include in the test day. I'll test the script in rawhide to see if it works ok or need an update.

comment:21 in reply to: ↑ 20 ; follow-up: ↓ 22 Changed 3 years ago by aalam

Replying to igor:

Replying to rhe:

This test aims to check the login and native text on desktop is correctly displayed and translated. I didn't find any case including this. Can you point it out?

I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there

As far as I understand the test case https://fedoraproject.org/wiki/QA:Testcase_i18n_font_application has basically the same scope.

If you find that i18n_font_desktop is still valuable I can revert the change, no problem.

I guess you meant the QA:Testcase_ibus_input can replace it, right? QA:Testcase_ibus_input is more detailed, but hasn't been updated for a long time. Is there any step need be modified to adapt the F-15 test day?

Exactly, the ibus test case is far more detailed and seems to be version agnostic. I would like an opinion from aalam on this as well.

https://fedoraproject.org/wiki/QA:Testcase_i18n_input_application can co-exist with ibus test cases as it helps to enable/disable ibus (with im-chooser). It can be modified to test only im-chooser.

Can we add bugs (already filed or fixed) on test pages, so that people can easily test issue (or possible issues) (like gnome-shell and ibus bug: https://bugzilla.redhat.com/show_bug.cgi?id=669481)

comment:22 in reply to: ↑ 21 ; follow-up: ↓ 23 Changed 3 years ago by igor

FYI: I placed draft pages for all i18n/l10n Test Days on wiki, as follows:

Replying to aalam:

I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there

I believe they are working on that but if it's not available until the test day we can change that step for using system-config-language.

https://fedoraproject.org/wiki/QA:Testcase_i18n_input_application can co-exist with ibus test cases as it helps to enable/disable ibus (with im-chooser). It can be modified to test only im-chooser.

Ok change reverted and test case added to Test Day page.

Can we add bugs (already filed or fixed) on test pages, so that people can easily test issue (or possible issues) (like gnome-shell and ibus bug: https://bugzilla.redhat.com/show_bug.cgi?id=669481)

Good idea! Added to the i18n desktop test day page as a nice to test situation.

comment:23 in reply to: ↑ 22 ; follow-up: ↓ 25 Changed 3 years ago by rhe

Replying to igor:

FYI: I placed draft pages for all i18n/l10n Test Days on wiki, as follows:

Thank you, I adjusted them a bit using current test day page format.

Replying to aalam:

I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there

I believe they are working on that but if it's not available until the test day we can change that step for using system-config-language.

I saw this problem as well. I think it's important to configure them at gdm or through an alternative way. AFAIK, Using system-config-language requires reboot to work, that will limit the use of live image chosen by most testers.

https://fedoraproject.org/wiki/QA:Testcase_i18n_input_application can co-exist with ibus test cases as it helps to enable/disable ibus (with im-chooser). It can be modified to test only im-chooser.

Ok change reverted and test case added to Test Day page.

AFAIK Im-chooser test is covered by QA:Testcase_i18n_input_method, isn't it?

Can we add bugs (already filed or fixed) on test pages, so that people can easily test issue (or possible issues) (like gnome-shell and ibus bug: https://bugzilla.redhat.com/show_bug.cgi?id=669481)

Good idea! Added to the i18n desktop test day page as a nice to test situation.

+1.

Btw, for the font desktop test, it is to check the fonts displayed on the desktop including the menus. This is not included in the font application test which aims to check the fonts in an application. So I prefer to keep both in the test day.

comment:24 Changed 3 years ago by adamwill

  • Cc tfujiwar@… added

A good person to have in CC for this (if he's not already) would be Takao Fujiwara, who works on ibus and is looking after getting ibus integrated with GNOME Shell. We definitely need to check GNOME 3's i18n/l10n smarts, I wanted to do it as part of the GNOME 3 test days but didn't manage to get test cases in for the first one. I will add Takao to CC, assuming it works (trac's CC field is a bit weird).

comment:25 in reply to: ↑ 23 ; follow-up: ↓ 26 Changed 3 years ago by igor

Replying to rhe:

Replying to aalam:

I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there

I believe they are working on that but if it's not available until the test day we can change that step for using system-config-language.

I saw this problem as well. I think it's important to configure them at gdm or through an alternative way. AFAIK, Using system-config-language requires reboot to work, that will limit the use of live image chosen by most testers.

If GNOME is able to log off (it hangs sometimes) then s-c-language works on live images. I added steps for this on font application test. I also realize that using GNOME's language selector application is not an option since it's not system-wide therefore doesn't reflect on GDM strings.

Btw, for the font desktop test, it is to check the fonts displayed on the desktop including the menus. This is not included in the font application test which aims to check the fonts in an application. So I prefer to keep both in the test day.

Since accessing menus are part of running applications I added a few steps to include menus rendering on font application test. IMHO we don't need separated test cases for menus and application, having both on the same test case can keep tests more straightforward.

comment:26 in reply to: ↑ 25 Changed 3 years ago by rhe

Replying to igor:

Replying to rhe:

Replying to aalam:

I tested gnome-shell, but gdm did not provide any way to select language or keyboard till today, not sure if we are able to follow step mentioned over there

I believe they are working on that but if it's not available until the test day we can change that step for using system-config-language.

I saw this problem as well. I think it's important to configure them at gdm or through an alternative way. AFAIK, Using system-config-language requires reboot to work, that will limit the use of live image chosen by most testers.

If GNOME is able to log off (it hangs sometimes) then s-c-language works on live images. I added steps for this on font application test. I also realize that using GNOME's language selector application is not an option since it's not system-wide therefore doesn't reflect on GDM strings.

Okay, thanks for clarifying this.

Btw, for the font desktop test, it is to check the fonts displayed on the desktop including the menus. This is not included in the font application test which aims to check the fonts in an application. So I prefer to keep both in the test day.

Since accessing menus are part of running applications I added a few steps to include menus rendering on font application test. IMHO we don't need separated test cases for menus and application, having both on the same test case can keep tests more straightforward.

It makes sense to me. Thanks.

comment:27 follow-up: ↓ 28 Changed 3 years ago by rhe

Hi Igor,

L10n desktop test day is coming tomorrow, I noticed the example of a test result is a link to the template page. Do you want testers directly post their results to your template page? I think it's better to create another result page based on the template, so I created https://fedoraproject.org/wiki/QA:Fedora_15_l10n_Results_2011-03-08 with a few adjustments, feel free to change it. Besides, some packages have no steps(ie. issue command), should we add another way to test them? And for the column 'built status', what is this supposed to be? Do we need this column in the result page? Please don't forget to send out the announcement when you are satisfied with them. Thanks.:)

comment:28 in reply to: ↑ 27 Changed 3 years ago by igor

Replying to rhe:

Hi Igor,

L10n desktop test day is coming tomorrow, I noticed the example of a test result is a link to the template page. Do you want testers directly post their results to your template page? I think it's better to create another result page based on the template, so I created https://fedoraproject.org/wiki/QA:Fedora_15_l10n_Results_2011-03-08 with a few adjustments, feel free to change it. Besides, some packages have no steps(ie. issue command), should we add another way to test them? And for the column 'built status', what is this supposed to be? Do we need this column in the result page? Please don't forget to send out the announcement when you are satisfied with them. Thanks.:)

What I had in mind for this was that translations teams could use the template to create a new page and link that page into the Test Day page. I came up with this approach because I thought that just one result page could be confusing since we will have results for several languages. Probably I should have documented it better. Since we already have result on your page due to timezones differences we can keep using it, no problem. I'll just add a language tag information to the header so new testers can add this information.

Those few packages who have no steps are usually hard to deploy packages. For instance smoon, the smolt server, which there are no straightforward way to test. We definitively need to come up with a way to test those packages for next releases test days but ask translators to set up a whole environment certainly is not a good idea. Although not optimal for the test day, translators can still review the .PO file.

That column "build status" was something I kept from the first template made by Noriko. I guess she wanted to keep track of packaging status by that time. For the test days I really don't see much use for this column so I can remove it from the results page you have created.

I'll send the test day announcement shortly.

comment:29 follow-up: ↓ 30 Changed 3 years ago by adamwill

What's the purpose of the link under 'Test Cases' which points to https://fedoraproject.org/wiki/QA:Fedora_15_l10n_Results_Template ? It's not a test case, and it just seems wrong to me; should it be removed?

comment:30 in reply to: ↑ 29 ; follow-up: ↓ 31 Changed 3 years ago by igor

Announcement sent to -test-announce and L10N list.

Replying to adamwill:

What's the purpose of the link under 'Test Cases' which points to https://fedoraproject.org/wiki/QA:Fedora_15_l10n_Results_Template ? It's not a test case, and it just seems wrong to me; should it be removed?

That was because the results template were supposed to work as test cases here, for translators know what packages to test. Since Hurry changed it to one results page for all teams that link isn't necessary anymore so I removed it.

comment:31 in reply to: ↑ 30 Changed 3 years ago by rhe

Replying to igor:

Announcement sent to -test-announce and L10N list.

Replying to adamwill:

What's the purpose of the link under 'Test Cases' which points to https://fedoraproject.org/wiki/QA:Fedora_15_l10n_Results_Template ? It's not a test case, and it just seems wrong to me; should it be removed?

That was because the results template were supposed to work as test cases here, for translators know what packages to test. Since Hurry changed it to one results page for all teams that link isn't necessary anymore so I removed it.

The page looks better, and I like the idea to use lang_CODE in result status.:) I've also redirected current page to this test day and changed irc topic on #fedora-test-day. So let's get it started!

comment:32 Changed 3 years ago by igor

  • Resolution set to fixed
  • Status changed from new to closed

Test Days recap sent to test-announce mailing list.

It is always a pleasure working with you guys. Thanks Hurry, Alam and Adam for your help, contributions and suggestions. :)

Note: See TracTickets for help on using tickets.