----- Original Message -----
Hey, folks. I'm not really sure how to frame it, but the result
of
all
my poking about at keyboard layout bugs and related stuff recently is
that I'm pretty sad at the state of support for
anything-but-U.S.-English in Fedora 18.
Here's the tally:
*
https://bugzilla.redhat.com/show_bug.cgi?id=889562 - systemd
conversion from xkb to console layouts fails probably more than it
succeeds, when it does, you wind up with U.S. English as your console
layout, not whatever you picked during installation
Lennart already commented this one. The real solution is long term one,
possibility of keymap updates.
*
https://bugzilla.redhat.com/show_bug.cgi?id=891487 - anaconda
doesn't
seem to manage to offer all the keyboard layouts it could do, and
some
of the ones it's missing are somewhat important
Already accepted as NTH, Vratislav does not have idea why some layouts
are missing, asking him to take a closer look.
*
https://bugzilla.redhat.com/show_bug.cgi?id=891489 -
anaconda's
mapping of 'native' layouts to user's chosen install language doesn't
work in all cases
Already accepted as NTH, partial patch available. For the rest -
mapping from languages is not supported - long term solution is to
prepare such table and to have someone who would maintain it (i18n
guys?) as it's not directly related to Anaconda and requires know-how
the team does not have (and should not have).
*
https://bugzilla.redhat.com/show_bug.cgi?id=878433 (?) - GNOME has
a
weird predilection for coming up with the obscure 'Bambara' layout in
user sessions after an install in a non-English language, but not the
correct layout for that language
*
https://bugzilla.redhat.com/show_bug.cgi?id=881624 - X and GNOME
keyboard layouts revert to U.S. English on upgrade to F18
*
https://bugzilla.redhat.com/show_bug.cgi?id=854557 - the 'layout
testing' in the keyboard spoke doesn't work at all how you'd expect
it
to
The patch is available but breaks string freeze. I'm going to ask
Translation team on today's Readiness meeting if they would be willing
to grant exception for this one.
*
https://bugzilla.redhat.com/show_bug.cgi?id=882440 - in fact,
people
have various problems interacting with and understanding the keyboard
spoke at all, really. Several of the issues discussed in this bug are
'greatest hits', especially the lack of a default layout switch
command,
the fact that anaconda doesn't automatically start using a layout you
promote to the top of the list, and the lack of any kind of indicator
in
anaconda as to what layout is in use
This is more an usability problem. Usability testing is planned, this
task should be added to test coverage. Targets F19.
We are back to mapping table maintenance, see above -> probably long
term ones, not low hanging fruits as I thought originally.
As Josef pointed out - we were hitting similar/same bugs in previous
releases - there's no clear regression as far as I read it, not saying
it's ideal and to hide our eyes problem does not exist. There are
potential quick fixes available to make the user experience better,
accepted as NTHs with patches available (but with some dependencies we
can try to sort out).
(there's a few more along those lines which I won't bore
anyone with)
In addition to those bugs, we have fairly significant regressions in
the
completeness of anaconda translations between Fedora 16 and Fedora 18
(the numbers for F17 for some languages are weird - a lot of
languages
show 55% completion for F17 but 90-100% for F16, which seems bogus,
as
I'm sure things didn't change that much between F16 and F17, so I'm
just
using the F16 numbers. I assume there's some weirdness that explains
the
odd 55% numbers for F17, but if not, hey, F17 was kinda boned
too...):
Language F16 F18
Finnish 93% 75%
Indonesian 100% 33%
Kannada 94% 33%
Oriya 94% 27%
Telugu 94% 32%
Bengali (India) 93% 33%
Portuguese 100% 36%
Persian 95% 27%
Malayalam 78% 20%
NorwegianBokmal 92% 55%
Bengali 93% 33%
Sinhala 93% 27%
Serbian 81% 23%
Serbian(Latin) 81% 23%
Hebrew 83% 22%
Catalan 68% (98% F17) 25%
Latvian 88% 20%
Greek 68% 21%
Turkish 79% 21%
Maithili 67% 18%
Asturian 85% 24%
(from
https://fedora.transifex.com/projects/p/anaconda/ )
There are several others around the 50-70% complete mark for F16,
too, I
just cut off at 67%. It's a fairly long list of languages for which
we
previously had tolerably complete translation coverage, but we now
have
a level which isn't really usable: basically these languages have
gone
from 'covered' in at least F16 (probably F17 too) to 'not covered' in
F18. I want to stress I'm not blaming anyone for this: I don't see
how
it could be otherwise, the problem is the huge amount of string churn
caused by newUI, I'm actually more amazed at how many languages _do_
have close-to-100% translations for F18 than how many _don't_, given
the
conditions. It's just an unfortunate thing.
Well, we accepted the change, the scope was huge and as we already know,
it's not a run for one release. Unfortunate but still kudos to all
people involved.
anaconda does not list every available translation for the user to
choose from, but I cannot figure out for the life of me how the
decision
about which to display is made: it's not that very incomplete
translations are left out, as plenty of very incomplete translations
(including most of the above) are shown. If we filtered out very
incomplete translations we might at least look a bit less silly, but
we
don't seem to be doing that. Our language selection screen is
definitely
writing checks that our translations can't cash :)
Let's ask Anaconda, would be great to know the decision making process,
maybe it's just oversight.
I don't really know where we need to go with this, exactly, but a
few
questions arise naturally:
1. In the short term, is the combination of all these factors enough
for
us to want to delay F18 further to try and make things suck less?
2. If not, do we want to engage in some Messaging around the F18
release
to emphasize that we know there are all these issues and we'll try to
smooth things out for F19?
3. In the longer term, how can we get anaconda, i18n, systemd, GNOME
etc
folks all pointed in the same direction and working so that there's
far
less suckage and far more smooth interaction going on here? Should we
try and run some sort of session at FUDCon?
If anyone wants to discuss this, I think Go/No-Go meeting + Readiness
meeting that follows is a good opportunity for it. After looking more
closely, we have a very nice feature requests, not a bad regressions
or issues that could not be documented as common bug.
Jaroslav
Thanks, folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list