Crimean Tatar (Crimean Turkish) locale (crh) is not shown in gdm languages list, even if language support for crh is added

Linking to language selector: that's the best i can think of at the moment.

Please let me know if i should attach a patch for this. I could easily make both packages by tweaking a currently supported locale, and attaching a .tar. Just 1 question:
Should the contents of
language-pack-crh-base:data/crh/LC_MESSAGES
be included in such a patch?

Thanks.

Please no patch!

Language packs are generated entirely automatic.

The reason why crh is missing, is that it either didn't have any translations in Launchpad when the first -base packages were built, or that they were missing in the full export from Launchpad.

Anyways, it will be fixed with the next full export, which might happen tonight UTC time. We will probably have language packs for crh available at the beginning of next week.

To get the native name displayed in language-selector, please make sure the corresponding language name entry in the iso-639 and iso-639-3 templates are translated into your native language. Likewise for the country name in iso-3166.

Arne Goetje wrote:
> Anyways, it will be fixed with the next full export, which might happen
> tonight UTC time. We will probably have language packs for crh available
> at the beginning of next week.

OK, make that "end of next week"... there is currently some trouble on
the Launchpad side and I need some fixes to go in first before I can
request an new full-export.

Hi Arne,

Did you mean you this would be released in mid-March? I tried it today, and no changes yet: crh is still not available in language selector. Which l10n packages are available also hasn't changed since Feb. 27:
Available (these packages started to get built in October of last year):
language-pack-gnome-crh: https://launchpad.net/ubuntu/+source/language-pack-gnome-crh/
language-pack-gnome-crh-base: https://launchpad.net/ubuntu/+source/language-pack-gnome-crh-base/

Unavailable:
language-pack-crh
language-pack-crh-base
language-support-crh

I want to make sure we have the right diagnosis, and that we get this fixed with the first shot.

P.S. I wonder whether the building of the currently unavailable packages depends on whether or not a Crimean Tatar (Crimean Turkish) team is listed under Translators Group.

Also, will users be able to add Crimean Tatar (Crimean Turkish) support from Language Support menu item once 1 or more of the following packages are released:
language-pack-crh
language-pack-crh-base
language-support-crh

Just want to make sure whether this is the only "missing link".

Thanks.

OK, the issue is, that the -base package is not generated. We will fix this in langpack-o-matic, which builds the packages.

Just a bit more info, in case it's relevant. Alacarte package for some reason doesn't have a .po import from upstream, although gnome-panel, which upstream was translated later than alacarte, does have a .po import from upstream. If this tells you anything, please take it into account. If not, then i guess it can be ignored for the time being, and hopefully alacarte will get pulled sometimes soon as well.

Thank you so much for working on this. I look forward to Ubuntu's language support for Crimean Tatar (Crimean Turkish).

> OK, the issue is, that the -base package is not generated. We will fix this in langpack-o-matic, which builds the
> packages.

Pleaease tell me that this is on track for Crimean Tatar (Crimean Turkish) language support to be available with the Jaunty release? I hope very much to be able to test this out w/ the Beta release.

P.S. Just an FYI: alacarte .po did get pulled into launchpad from upstream earlier this week, so there doesn't appear to be any issue w/ gnome language packs.

Regards.

Turns out when i posted my last update on 03-21, 2 out of 3 packages were already available since 03-16. This was a good news, because now language support can be added as user-default language once the user is logged on.

However, the following package is still not available:
language-support-crh

I believe that is why Crimean Tatar (Crimean Turkish) isn't listed among available languages in the gdm login screen, even after selecting it to be available there. So it cannot be used unless the user previously selected it as the default locale.

To wrap up, this bug appears to be 66.6% resolved. Apparently it will be 100% resolved once language-support-crh is available. I hope so much that language-support-crh will be available w/ Beta.

Thank you.

Reşat SABIQ wrote:
> Turns out when i posted my last update on 03-21, 2 out of 3 packages
> were already available since 03-16. This was a good news, because now
> language support can be added as user-default language once the user is
> logged on.
>
> However, the following package is still not available:
> language-support-crh
>
> I believe that is why Crimean Tatar (Crimean Turkish) isn't listed among
> available languages in the gdm login screen, even after selecting it to
> be available there. So it cannot be used unless the user previously
> selected it as the default locale.
>
> To wrap up, this bug appears to be 66.6% resolved. Apparently it will be
> 100% resolved once language-support-crh is available. I hope so much
> that language-support-crh will be available w/ Beta.

language-support-crh is not necessary. the language-support-* packages
are meta packages with dependencies on other useful pckages in the
archive. For example thunderbird or openoffice.org translation packages,
spell checkers, etc. This is purely optional.

The packages which needs to be present for the language to be selectable
is language-pack-crh-base.

I have just uploaded new -base language packs for jaunty. Once they went
through the build process, your language should be usable. Please use
language-selector to install and activate the language.

The non-GNOME package exists now: https://launchpad.net/ubuntu/+source/language-pack-crh

So this should be working for crh now.

I see that language-support-crh doesn't appear to affect the remaining gdm issue, but after spending many hours on it today, i still see that the following issue is outstanding:

crh isn't listed among available languages in the gdm login screen, even after adding language support for crh locale. So it cannot be used unless the user previously selected it as one's default locale. This issue doesn't exist for az, or tr locales: i can see them in gdm languages list after adding language support for them.

I've confirmed this on 2 machines, including performing a partial upgrade on one of them to sync up w/ the latest packages available.

Simple test case:
1. Add language support for crh and tr.
2. Log out.
3. Check gdm languages list: tr is there, crh isn't.

Is this a gdm issue, or something missing in a file like /etc/locale.alias, i am not sure. I was told at Gnome that they don't keep any locale settings in gdm anymore, and yet here we are. I would highly appareciate if you have any thoughts on this.

Thanks.

Btw., i don't think .orth could be causing gdm language selection issues, but is there any chance that it could be a factor?
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/339396

Thanks.

Reşat SABIQ wrote:
> Btw., i don't think .orth could be causing gdm language selection issues, but is there any chance that it could be a factor?
> https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/339396

I don't think that's related.
It seems to be a gdm bug, I'm currently trying to confirm it.

In the meantime yo can use language selector to set the user language to
crh.

Indeed, crh needs to be added to /etc/gdm/locale.conf .

FYI, i have tried adding the following manually to this apparently generated file, but it did NOT resolve the gdm issue:
Crimean_Tatar;_Crimean_Turkish(Ukraine) crh_UA
Crimean_Tatar;_Crimean_Turkish(Ukraine) crh_UA.UTF-8

I gave it about 30 minutes, maybe i missed something, but it doesn't appear to be something that can be resolved w/ manual changes to that file alone. Of course, since it's generated, ideally it would be done in the source.

Is this a gnome bug, or a distro bug? I have a tracking bug on this subject at gnome, so depending on how this is resolved, i may need to update or close the gnome bug. I hope this can be fixed in time for final jaunty release.

Thanks.

Despite my inability to manually get it to work, as mentioned in my last comment, Martin might well be right about /etc/gdm/locale.conf being the roadblock, and it might start working when the package is built in a manner that addresses this.
I hope this can be addressed in gdm in time for jaunty release.

P.S. As a side note, in case this tells anything to anybody, crh is also missing from the following, but i do not know whether that affects the gdm languages list issue:
a. /usr/share/language-selector/data
b. /usr/share/locale/

I'm wondering if there is any way to get the gdm languages list issue resolved before final jaunty release, for which apparently the time is running out.
I'm busy trying to do some last minute translations, but if there's anything i can do to help resolve the gdm issue, please let me know.

Thanks.

I forgot to mention: i'm wondering if ; character in language name spelling might be causing such hard to diagnose side effects, because it appears to be a "reserved" character at least in one the files involved.
Please feel free to change ; to another character, which should be OK temporarily, and maybe even in the long run.

I wonder whether upgrading
http://packages.ubuntu.com/jaunty/iso-codes
which is currently based on 3.6, to 3.7 or 3.8 would resolve the gdm languages list issue, although the only additional relevant thing provided w/ those releases is crh.po files.

P.S.
I don't know whether it matters, but I don't see crh listed in:
/iso-codes-3.8/notes/language-in-locales.txt
and
/iso-codes-3.8/notes/territory-in-locales.txt
And the same for 3.7.

Reşat SABIQ wrote:
> I wonder whether upgrading
> http://packages.ubuntu.com/jaunty/iso-codes
> which is currently based on 3.6, to 3.7 or 3.8 would resolve the gdm languages list issue, although the only additional relevant thing provided w/ those releases is crh.po files.
>
> P.S.
> I don't know whether it matters, but I don't see crh listed in:
> /iso-codes-3.8/notes/language-in-locales.txt
> and
> /iso-codes-3.8/notes/territory-in-locales.txt
> And the same for 3.7.
>

It won't solve the issue with gdm, since gdm doesn't use iso-codes yet.

I was kinda tilted to thinking in that direction after seeing this bug upstream:
https://alioth.debian.org/tracker/index.php?func=detail&aid=311588&group_id=30316&atid=413077

I guess what you mean is that that bug refers to another distro, where gdm uses iso-codes, and it doesn't apply to Ubuntu yet.

In that case, i'm in the dark on this bug here then. Just to re-iterate the earlier discussions, crh is missing in the following places:
1. /etc/gdm/locale.conf
2. /usr/share/language-selector/data
3. /usr/share/locale/

Perhaps the 1st step towards fixing gdm languages list issue should be ensuring that it's present in the above locations.

Thanks.

I am now aware that apparently language-support-crh package isn't related to gdm languages list, but the following is probably still related to this bug:

The firefox .xpi import has succeeded, but apparently it's not been released w/ 04/10 full export from launchpad. The following package is still not being built:
launchpad.net/ubuntu/+source/language-support-crh

So we have 2 outstanding issues here, the first one probably being a bit more important, assuming that people can learn to install the .xpi on their own:
I. GDM languages list isn't listing crh among installed locales, even if it's installed.
II. language-support-crh package isn't being built yet.

P.S. I'm guessing, II. might be something easy that only requires a flip of a switch, whereas on I. we currently don't appear to have a roadmap yet.

The firefox translation should actually be provided by language-pack-crh-base. Although the .xpi was imported on the 8th, firefox translation still wasn't provided by language-pack-crh-base after last Friday's full export from launchpad.
If it's still possible to fix up language-pack-crh-base package to include firefox translations w/ initial jaunty release, that would be great. I'll check it in 24 hours, but it probably won't include firefox translations unless something is tweaked, otherwise it would've picked it up on the 10th.

Regarding the GDM lang list issue:
i. i've tried installing iso-codes-3.8 from source and the gdm lang list issue persisted.
ii. i've also tried removing ';' character from the locale name, and make installing iso-codes-3.8 with this tweak, and the gdm lang list issue persisted.

This probably means the issue isn't related to iso-codes. It's either an Ubuntu GDM customization bug, or a bug in upstream, although upstream i was told they didn't do anything to support any locales anymore.

One more note:
When i tried to change GDM locale during signon from default crh_UA.UTF-8 to some other locale, the warning verbiage included "crh_UA.UTF-8" rather than locale name. That might be a useful indication to start looking into the root cause.

I split out Firefox packaging issue into a separate bug:
https://bugs.launchpad.net/ubuntu/+source/language-pack-crh-base/+bug/363264

This bug is now only about GDM languages list issue.

Hopefully, this will help a bit in tracking and fixing outstanding issues in a more organized and efficient manner, and the easier issue could be closed separately w/o having to wait for both issues to be resolved.

Turns out Ubuntu is using an old version of gdm, which, unlike 2.24 or 2.26 in fact does appear to compile locales in. I'm not sure whether the locales are taken directly from the Ubuntu gdm source file
gdm-2.20.10/config/locale.alias
or an external file maintained by i18n team, but it is quite clear that the supported locales are compiled into the
/usr/lib/gdm/gdmgreeter
and/or
/usr/lib/gdm/gdmlogin
.

Can i request the following before the final jaunty release?
1. addition of the following or its equivalent to gdm-2.20.10/config/locale.alias or its equivalent:
CrimeanTatar(CrimeanTurkish) crh_UA.UTF-8,crh_UA
2. new build of the gdm module to compile the missing locale in.

jaunty cds are being built so that will not be changed in jaunty now

I think if this was considered important, it would still make it on time, as the official release date is the 23rd, and there's still plenty of time even until midnight between the 21st and the 22nd.

The question appears to be:
Does this qualify for freeze exception process, considering also that it's a trivial update that doesn't change functionality, and only adds another language to an existing languages list for user's that install support for that language?

Thanks.

validating the CD images take several days, jaunty iso are already rolled and being tested

I understand that chances of this bug being treated as a "very high-priority showstopper bug" are not very high, and it may indeed be too late to address this in jaunty, but would still like to try and bring this to the attention of ubuntu-release team for a freeze exception evaluation.

I've seen similar bugs logged for Asturian, and Yoruba, although i do not know whether they've since already been resolved.

1. Description of the proposed changes:
1.1. adding 1 or more locales currently excluded from gdm to
gdm-2.20.10/config/locale.alias
(or an external file maintained by i18n team, if any).
1.2. re-building and releasing a new version of gdm.
2. A rationale for the exception, explaining the benefit of the change: language(s) currently not listed in gdm languages list even after support for them has been added, would then be listed in gdm languages list.
3. Any additional information: this should not be a risky update to make, because it doesn't change any functionality, only adding 1 or more languages to the existing gdm languages list, only affecting and benefiting the people who will add language support for those locales.

If it is too late for initial jaunty release, i would like to request an evaluation of this being fixed in a stable release update (ubuntu-sru).

Thanks.

Sorry, no, this is not a candidate for a freeze exception. Such a change would require remastering and retesting the Ubuntu ISOs. Unsubscribing ubuntu-release.

It could be considered for an SRU according to the process at <https://wiki.ubuntu.com/StableReleaseUpdates>. However, my opinion is that it doesn't meet the criteria for SRU, and that the focus should be on addressing this for karmic forward.

I tried to patch /etc/gdm/locale.conf, config/locale.alias, debian/locale.conf, and gui/gdmlanguages.c, nothing seems to help. I can't see another place where languages are defined. This entire locale system in gdm is totally broken, I hope that the new gdm will have this cleaned up. Can you take this up with upstream, perhaps?

> Can you take this up with upstream, perhaps?

The latest gdm probably doesn't have any such issues. Fedora 11 Preview that i tried (both installed, and even Live CD), shows Crimean Tatar (Crimean Turkish) locale in gdm just fine, and it really made me feel good when i first saw it. Once i verify that Fedora uses up-to-date gdm, i will close my upstream bug related to this question (which didn't get any feedback anyway).

Is upgrading gdm to the latest version considered for 9.10? If yes, most likely this issue will be resolved automatically.
If not, i don't think upstream will be interested in patching an old release or figuring out how to handle crh locale in it.

P.S. I tried building ubuntu's gdm from source myself a few weeks ago, but i think i don't quite know how to configure its build, because i ended up w/ vanilla-like gdm screen, which still didn't show me crh locale.

Thanks.

the new gdm will probably not be used in karmic no, it still doesn't have a configuration tool for example

The langpack-o-matic part is handled in bug 422760 now. (For building the default locales).

In Karmic's gdm, Crimean Tartar is now shown properly in the language selector.