#51 closed enhancement (wontfix)
how to find my own language
Reported by: | erikos | Owned by: | sayamindu |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Sugar | Version: | Git as of bugdate |
Severity: | Major | Keywords: | r- |
Cc: | eben.eliason@… | Distribution/OS: | Unspecified |
Bug Status: | Assigned |
Description
Model a: translate the language options to the current locale: English, Spanish, German...
Model b: display the language options in the original language: English, Espanol, Deutsch...
The latter model is what gdm is using. I think it makes sense, because you should be able to always at least find 'your' language. Eben what are your thoughts on this?
Attachments (1)
Change History (18)
comment:1 Changed 15 years ago by erikos
- Owner changed from marcopg to unmadindu
- Status changed from new to assigned
comment:2 Changed 15 years ago by sayamindu
- Owner changed from unmadindu to sayamindu
- Status changed from assigned to accepted
comment:3 Changed 15 years ago by eben
comment:4 Changed 14 years ago by sayamindu
- Keywords r? added
The way GDM does this is not very efficient, unfortunately. I have attached a patch, but I don't know if this is going to make sense (performance wise) on an XO.
I had to resort to a hack to force sorting make sense though.
comment:5 follow-up: ↓ 7 Changed 14 years ago by erikos
Hmm, it takes quite a while to load the language section (noticeable on my T61 as well). Is this the only way to generate the information? Maybe making it async?
comment:6 Changed 14 years ago by sayamindu
- Keywords r- added; r? removed
- Version set to Git as of bugdate
I don't think it will be possible to add a better performing solution at this stage (we are already at freeze). Implementing an async solution would require us to implement a custom treemodel, which may be too invasive and complicated at this stage.
comment:7 in reply to: ↑ 5 ; follow-up: ↓ 8 Changed 14 years ago by garycmartin
Replying to erikos:
Hmm, it takes quite a while to load the language section (noticeable on my T61 as well). Is this the only way to generate the information? Maybe making it async?
Testing Joyride 2631 on XO-1, this click take 6 or more seconds to have any visible effect! The user is given the impression they did not click at all or that something crashed (luckily multiple clicks on the Language icon does not appear to bork anything). Would it be possible to modify the mouse cursor to show the spinning wait icon?
comment:8 in reply to: ↑ 7 Changed 14 years ago by tomeu
- Milestone set to 0.86
Replying to garycmartin:
Testing Joyride 2631 on XO-1, this click take 6 or more seconds to have any visible effect! The user is given the impression they did not click at all or that something crashed (luckily multiple clicks on the Language icon does not appear to bork anything). Would it be possible to modify the mouse cursor to show the spinning wait icon?
Opened #245 about that. Moving this one to 0.86.
comment:9 Changed 14 years ago by gregdek
- Bug Status set to Assigned
- Distribution/OS set to Unspecified
- Severity set to Blocker
comment:10 Changed 14 years ago by erikos
- Milestone changed from 0.86 to 0.88
- Severity changed from Blocker to Major
- Type changed from defect to enhancement
This is not a blocker, and the proper fix would be invasive, so I move to 0.88
comment:11 Changed 13 years ago by sayamindu
The only way to fix this seems to ship a pre-built list of translations, and look that up while building the list. Does that seem acceptable ?
comment:12 Changed 13 years ago by walter
- Milestone changed from 0.88 to 0.90
We should settle on a solution to this (and also consider http://wiki.sugarlabs.org/go/Features/Feature_intro_language_keyboard_options as well)
comment:13 Changed 12 years ago by Rohit U
Is speed still an issue? Should I try implementing an async method?
comment:14 follow-up: ↓ 15 Changed 12 years ago by sascha_silbe
Choosing language and time zone is a distro level issue. Sugar currently does it itself (sometimes), but that brings in a whole lot of trouble. See a recent mail about problems with the time zone code. #1492 and #1672 are blockers bugs for the keyboard layout support that are still unsolved. At least one distro has reported issues with Sugar settings (~/.i18n) vs. locale chosen via the display manager.
The way forward is to move this out of Sugar as much as possible.
On systems using a display manager with login prompt, that's a good place to put it (and should be the default). For systems that boot straight into Sugar, we'll need to retain an in-Sugar way of changing things, but it should offload as much as possible to other code. We should take a look at how Gnome handles this. There's a chance they already solved this issue and we can build on their code.
comment:15 in reply to: ↑ 14 Changed 12 years ago by sascha_silbe
Replying to sascha_silbe:
[...] #1492 and #1672 are blockers bugs for the keyboard layout support that are still unsolved.
Sorry, that should have read #1942.
comment:16 Changed 10 years ago by dnarvaez
- Resolution set to wontfix
- Status changed from accepted to closed
This seems pretty tricky, not major and has been unfixed for ages. I doubt it helps to keep tracking it here. Patches welcome of course :)
I think (b) is the appropriate choice.