On Thu, 2013-01-03 at 16:14 -0500, Chris Lumens wrote: > > 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. > > Keep in mind that translations for a lot of these languages are > completely a volunteer effort, and there's no guarantee that volunteers > have the time or even interest to step up and do a whole new set of > translations. > > It was always going to be this way, unless we found or hired some very > motivated people to do all the translations, and we've explained that. > You're comparing years of maintainence effort on a pretty stagnant UI > with something that's not even been in a released product yet. Well, yes, in the context of whether we ought to make it into a released product yet. :) I didn't say it was a fair comparison. I explicitly said it wasn't. But 'is it a fair comparison?' is not the operative question in the context of trying to decide 'is what we have releasable?'. > > 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 :) > > The details are in pyanaconda/localization.py, but basically we're > displaying every language for which we have a .mo file. We'd talked > about ordering things on the language screen such that very incomplete > translations are sorted to the bottom or perhaps even hidden, but: (1) > there's no time, and plenty of serious bugs to fix; (2) partial > translations could be better than no translation at all, depending on > what's missing and what's not. FWIW, I actually looked at them all, and my take is that anything under 40% is very likely to be pretty much unusable. I think the bits that are complete in anything around the 40% mark or lower are left over strings from old releases: in such translations, the entire new UI is usually not translated, so it's just not navigable unless you understand English. All the hub names and descriptions are in English, all the new partitioning text is in English, etc. I fully recommend spending three hours running through the first three steps of install in every offered language, and a complete install in several of them. Actually I don't, it is mind-numbing tedium, but it *is* somewhat instructive. Actually, there's a bug with German I need to double-check, I just reminded myself...le sigh. > > 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? > > No. > > > 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? > > We can only do so much for translations. What we need is a way to > motivate speakers of a lot of these incomplete languages to join up and > help out. That's the main messaging tactic I think we should take. > > > 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? > > Perhaps. > > >From the anaconda perspective, we don't want to know a lot of this. > We'd really prefer to not have knowledge about keyboard layouts and > languages. We just want to grab the data from somewhere else and use > it, but for whatever reason it seems like there's a lot of problems and > a lot of components moving in different directions. Yes, I know that's what anaconda would like, and I think it's a good idea. But what I'm worried about is, really, the same as you: the case where anaconda says "we just don't want to do this work any more, there should be a sane 'upstream source' for us to take it from", but the 'sane upstream source' doesn't actually appear. That isn't an optimal situation, and to a degree, it's what we have now: we're not doing weeding of 'supportable' keyboard layouts in anaconda any more, we're just throwing the kitchen sink at the user, but we haven't made sure the selected configuration can actually be applied properly (viz the console layout problem). I agree that the fix for that is that we should be able to use xkb keymaps on the console, but if that doesn't happen - if no-one actually writes that code - then what we have is a significant functional regression. Ditto the issue of mapping countries to keyboards: I agree that we want to be doing as little of that as possible in anaconda, but if no-one else takes up the slack, then what we get is worse than what we had. To a large degree this is "not your problem", but it _is_ Fedora's problem, and I fully intend to keep making a nuisance of myself all over the place until the magic upstream sources for this information actually appear. :) On the country/keymap thing, a concrete suggestion: I am not sure it's even a good idea to _attempt_ such magic. How about something simpler? If you pick any country other than the good ol' U.S.A., we force you through the keyboard spoke as the next step, before sending you to the hub. It's against the Awesome Hub/Spoke Design, but practically speaking, it may be a better option. -- 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
