There are several issues with FC5test3 installations performed in Serbian language
- 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
- 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@Latn.po, 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
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
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]
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
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
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