There are several issues with FC5test3 installations performed in Serbian language Major: - If Serbian is chosen as the language of installation, some of the buttons (most notably the bottom three "Release Notes", "Back" and "Next", but also "Ok" in some dialogs) are not translated. Same goes if Serbian(Latin) is chosen. Most of the text in the installation screens is translated ok though. Couldn't reproduce this with any other language I've tried. On the other hand, installation looks ok if I boot with "linux lang=sr_CS.UTF-8" - After the installation, the system locale is set to sr_CS.UTF-8@Latn in /etc/sysconfig/i18n regardless of the choice between Serbian and Serbian(Latin) during installation. Serbian should set it to sr_CS.UTF-8 and Serbian(Latin) to sr_CS.UTF-8@Latn, as specified in bug #175611 Minor: - In the language selection screen, it appears that the native description next to Serbian(Latin) is picked up from anaconda's sr.po (cyrillic version) instead of sr, i.e. it should be "srpski(latinica)" instead of "ÑÑпÑки(лаÑиниÑа)" - The combobox for choosing the action for partitioning layout is not translated All of these could be related and originating from the need to support two separate locales, sr and sr@Latn, because of the use of two scripts. Could it be that the "@" character is causing problems in some scripts (that was the case with the CVS server for example)?
Yeah, we're almost certainly hitting corner cases since this is exercising wholly new things for our language code. We'll try to figure out and fix. But, to play the worst case card, if we can't get it working in time for FC5, what would you prefer that we do? (we can definitely make one of the two work and I'll do what I can to fix things for both, but I'm not 100% sure that I'll get there and I want to have the contigency plan too :)
Although I'm crossing my fingers hoping it's an easy fix, if push comes to shove, I'd say we want the cyrillic one to be flawless (thats "Serbian" - sr_CS) and we can work on the latin one later (it has issues with glibc support beyond our scope atm, so it can be grudgingly considered second tier for now :). In the worst case, sr@Latn messages will still be shipped anyway for all the Fedora tools, this affects the install only? In that case, users reading only the Latin script could potentially perform the installation in Croatian or Bosnian, but switch the locale back after? We'd need some attention to bug #172600 then.
Saw some anaconda changes in rawhide so decided to try today's boot.iso - no graphical mode for language selection (doh), so couldn't test this... On the other hand, there is some new issues: text mode language selection does change the controls and strings (both Serbian and Serbian(Latin)) appropriately, but the text is not wrapped correctly in either case so the display becomes mangled quickly.
Okay, I think that I have this fixed now and it should be in tomorrow's rawhide. Can you test then and see if things look better and reopen if not.
Jeremy, just tested with todays rescuecd. Things do start off better: proper language names are now displayed, and buttons are properly translated when Serbian is chosen (not so for Serbian(Latin), but we can live with that if we have to for now). Then we get to keymap selection. (There is no listbox for selection any more, but the user is still asked to make a selection. This is a bit confusing, is this the intended operation? I did notice there's been a change in anaconda about keymap selection on Feb 27, just checking.) Anyhow, for installation in Serbian, on pressing "Next" we get an exception with the traceback: File "/usr/lib/python2.4/site-packages/rhpl/keyboard.py", line 131, in activate kbd + self.modelDict[console_kbd] KeyError: 'sr-cy' This could be related to bug #183325 I can work around this by selecting English first, going through the keymap selection, and then going two screens back to change the language back. I still have to confirm if /etc/sysconfig/i18n gets set properly once the network install is finished over here.
Ok, /etc/sysconfig/i18n settings seem to be ok now, so it's just the keymap exception that's a big problem for us.
Okay, fixed the serbian keymap not being listed in rhpl.keyboard_models which will fix the key error. Also, fixed anaconda's locale trimming code so that hopefully we'll keep the sr@Latn translations. I've filed a separate bug (bug 183718) for the fact that the keyboard screen isn't appearing.
Jeremy, thanks a lot for wotking on this, I can now confirm we have a working installation in Serbian. There are still a few creases left in the Latin variant, but it's not critical that they're ironed this time around if you're pressed for time, as we can make do with this right now. After choosing the language Serbian(Latin), the keyboard selection screen only gets the Cyrillic translation (don't know if that has anything to do with that new bug #183718), while all the following screens get the expected Latin one ok. Also, none of the buttons in any of the screens get the Latin translation at all.
Created attachment 125596 [details] Anaconda keymap selection screenshot Screenshot of keymap selection screen: the string at the top is in Cyrillic despite choosing Serbian(Latin) previously; also, the buttons at the bottom are untranslated
It looks like the root of the remaining problems might be the X locale database not having the right information for the sr locales. Given where we currently are, I don't see these really getting resolved for FC5. Definitely something to be sure gets tested early in the FC6 cycle so that we can get it all right.
The problem with setting the Latin variant during installation is still present in FC6test1. Would be great if there is now time to dig into this deeper so we figure out if this is due to anaconda or GTK/Xlib/glibc support for the sr locale(s), and, if latter, nail which one so we can file a bug upstream.
FC6T1:When istalling Finnish (latin1) keyboard keymap terminal window has wrong keymap. I don't know if it was the whole system, I fixed it by running setup on terminal. BTW, the text-mode "setup" program also had garbled outlook. It was readable and functional, but with extra characters and colour lines not ending where they should.
Okay, keyboard screen isn't showing up right because the package hasn't been rebuilt in ages; I did that so that the translation is actually being included :) And I think I figured out what's causing the gtk buttons to not show up right and have it fixed in CVS
Thanks for taking some time to look at this Jeremy. I can confirm that the keyboard screen is now displayed properly with the 10/03 rescuecd, but still no dice on the button labels. I guess we'll just need to wait until anaconda is built against the fixed gtk?
No, there shouldn't be any need to rebuild anything. For some reason, our locale-archive is still ending up missing bits. Need to investigate more.
Okay, not sure why but the locale-archive is actually _larger_ than the bits in /usr/lib/locale and if I go to just using the bits in /usr/lib/locale instead of a locale-archive, it works.
Guess it has something to do with glibc then, we don't have sr_CS@Latn accepted in it yet, because Drepper insists on the @latin qualifier - we first started using @Latn because it's ISO 15924 and it was recommended by GNOME devs as such. We're thinking of changing to @latin beacuse he won't budge, but that would mean a lot of renaming of po files in GNOME, KDE and all distro specific tools, which has to be a coordinated effort within our community. It might happen because we'll have to change the locale to sr_RS in the near future anyway. In any case having the script in the qualifier is imho wrong (because of how matching is done in glibc, it is usually discarded), CLDR way (e.g. sr_Latn_CS) is more correct if you ask me, but I don't see glibc supporting that any time soon since I guess it's still a subject of discussion.
Saw today's rawhide changelog, and I can confirm that 10/05 rescuecd instalation works and looks great in sr@Latn, thanks! Would be nice to know exactly where the problems was in case it crops up somwhere else.