Bug 473209 - [mai_IN] [ne_NP] Please add Maithili and Nepali languages to language selection menu in anaconda
[mai_IN] [ne_NP] Please add Maithili and Nepali languages to language selecti...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11Blocker/F11FinalBlocker
  Show dependency treegraph
 
Reported: 2008-11-26 23:17 EST by Parag Nemade
Modified: 2009-04-07 01:14 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-16 15:32:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Mai_IN_and_Ne_NP_lang addition patch (823 bytes, patch)
2008-12-02 23:37 EST, Parag Nemade
no flags Details | Diff

  None (edit)
Description Parag Nemade 2008-11-26 23:17:29 EST
Description of problem:
Maithili and Nepali languages are not available in the anaconda menu at install time. 

Version-Release number of selected component (if applicable):
anaconda-11.4.1.62-1.i386.rpm

How reproducible:
always

Steps to Reproduce:
1. Start Fedora installation
2. Proceed to the step that asks you to choose the language to use in the
install process

  
Actual results:
Maithili and Nepali languages are not in the list

Expected results:
Maithili and Nepali languages should be in the list

Additional info:
Comment 1 Matěj Cepl 2008-11-28 14:48:30 EST
There is nothing to triage here.

Switching to ASSIGNED so that developers have responsibility to do whatever they want to do with it.
Comment 2 Chris Lumens 2008-12-02 13:03:27 EST
As always, adding languages to anaconda requires the following:

(1) What LANG= setting should we use for each?
(2) What's the console font that should be used?
(3) What's the console and X keyboard setting for each?
(4) What packages contain the X font?
(5) Are the font and keyboard settings complete and usable?
Comment 3 Jens Petersen 2008-12-02 20:25:22 EST
Parag did you forget to attach your patch?
Comment 4 Parag Nemade 2008-12-02 23:21:36 EST
not exactly that I forgot to attach patch here. I just took reference from this bug 237060 about how requests should be added to Bugzilla for newer languages in anaconda where no input was provided in that bug.
Comment 5 Parag Nemade 2008-12-02 23:37:56 EST
Created attachment 325481 [details]
Mai_IN_and_Ne_NP_lang addition patch

clumens,
      I have attached patch here. If information from patch is still not enough for criteria to add new language in anaconda then ask for required information.
Comment 6 Chris Lumens 2008-12-03 10:08:54 EST
Parag - yeah that's a good start, thanks.  If you look at scripts/upd-instroot, you'll see (among other things) that we need to include the font packages and the font files themselves.  Are there special fonts needed for these languages, or are they already part of a package we're including?  Also, in the rhpl package you'll see the keyboard_models.py file which needs similar changes to what you've already done.
Comment 7 Parag Nemade 2008-12-05 01:45:38 EST
For Maithili,
    defualt font set is from package lohit-fonts-maithili as seen in comps file.

For Nepali,
    defualt font set is from package madan-fonts as seen in comps file.

I am not sure yet about rhpl modification as I see only 4 Indic languages out of 11 got entry there and still rest have no entry for their keyboard. Will check on this and report new bug.
Comment 8 Jens Petersen 2008-12-05 02:10:43 EST
My understanding is that PCs in India normally use/have a US keyboard, right?
Comment 9 Parag Nemade 2008-12-05 02:54:41 EST
(In reply to comment #8)
> My understanding is that PCs in India normally use/have a US keyboard, right?
 Yes. Normally US keyboard is used.
Comment 10 Matěj Cepl 2008-12-15 07:34:03 EST
What needs to be traiged here, that you moved this back to NEW?
Comment 11 Andy Lindeberg 2008-12-15 10:47:23 EST
Nothing needs to be triaged, but the bug is not assigned to anybody. As such, it belongs in NEW.
Comment 12 Matěj Cepl 2008-12-15 11:57:59 EST
Sorry, it doesn't -- please take a look at https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow (note, that this is the official FESCO approved, workflow). If you need distinguish between ASSIGNED == "triaged, and the next destiny of the bug is up to maintainers" and "actually somebody works on it", I would suggest to use ON_DEV for it.
Comment 13 Andy Lindeberg 2008-12-15 13:03:13 EST
And yet it is interesting to note that there are *zero* Fedora anaconda bug reports in ON_DEV. Either this means that nobody is working on anything, or the "official FESCO approved workflow" doesn't actually reflect the reality of how bugs get sorted. It should be fairly obvious which of these is the case.

So now the question is whether to abide by the official documentation, or to go with the system that the rest of the people I work with actually use. I'd be inclined to choose the latter in any case unless there was a really compelling argument against it, and that's ignoring the fact that in /this case/ specifically, it's more helpful to this bug report for it to be marked as NEW rather than ASSIGNED - /because/ the general interpretation is that ASSIGNED means "Somebody is working on this bug", those bugs get less attention from everybody but their assignees. For bugs that are /actually/ being worked on that's not a problem, but for bugs that are still listed as assigned to anaconda-maint-list, it can drastically reduce turnaround time. In contrast, bugs marked as NEW are more likely to be looked at by non-assignees, increasing the likelihood of a response, quick fix, or assignation for fixing.

In addition, having checked with clumens, that workflow is based around releasing updates, which we don't do. It is, therefore, flawed.
Comment 14 Matěj Cepl 2008-12-15 21:13:30 EST
(In reply to comment #13)
> specifically, it's more helpful to this bug report for it to be marked as NEW
> rather than ASSIGNED - /because/ the general interpretation is that ASSIGNED
> means "Somebody is working on this bug", those bugs get less attention from

No, it isn't and it actually never officially was (take a look for example at https://bugzilla.redhat.com/page.cgi?id=fields.html#assigned -- this text is there like forever). The problem with your interpretation is, that it doesn't take into account work of bug triagers, who if this stays in NEW, will hit this bug again and again and will switch it to ASSIGNED because there is nothing to triage here.

I totally understand that this is some work for you, but unfortunately, there are 4063 NEW bugs in Fedora bug triagers are struggling with, so I don't see any way how to change our ways easily.

> In addition, having checked with clumens, that workflow is based around
> releasing updates, which we don't do. It is, therefore, flawed.

OK, then I would please ask you to suggest how to move your bugs out of the NEW -- we can certainly help you, if there is a need to sift through a lot of bugs or something like that, but really NEW bugs should go away.

Please, catch me on IRC or anything, if you need to discuss it more.

Best,

Matěj Cepl
Comment 15 Parag Nemade 2008-12-15 22:42:32 EST
Why this bug gets moved back to NEW state whereas I have provided all required inputs here.
Comment 16 Jens Petersen 2008-12-15 23:12:46 EST
I think it would probably be better for the anaconda team to search for unassigned bugs than using state for that:

https://bugzilla.redhat.com/buglist.cgi?emailassigned_to1=1&emailtype1=exact&email1=anaconda-maint-list@redhat.com&product=Fedora&bug_status=NEW,ASSIGNED,NEEDINFO,MODIFIED (143 Fedora bugs)

You can of course narrow down more with &component=anaconda (142 bugs!) and more usefully &version={rawhide,10,..} (23, 82, 32, 5 bugs respectively).

https://bugzilla.redhat.com/buglist.cgi?product=Fedora&component=anaconda&bug_status=NEW,ASSIGNED,NEEDINFO,MODIFIED to see all open Fedora anaconda bugs, etc.  Probably good to bookmark and document on your wiki pages.
Comment 17 Chris Lumens 2008-12-16 11:51:51 EST
Parag - I see there's a special keyboard layout for Nepali (see /usr/share/X11/xkb/symbols/np), and that all the Indic languages have their layouts in /usr/share/X11/xkb/symbols/in as variants.  However, there is no variant for Maithili in that file.  Should I go ahead and use us for the keyboard layout as you indicated, or is another layout more appropriate?

That's the last bit of information required.
Comment 18 Parag Nemade 2008-12-16 23:36:06 EST
Yes. you are correct that we have xkb layouts already. But no one like to input in his locale at time of installation. people in India and so Nepal used to give input in English Characters only.
So I request you to please go ahead.
Comment 19 Jens Petersen 2008-12-17 18:46:24 EST
Right I don't think we should be using non-US xkb layouts for Indic languages by default - they do not support ascii input normally afaik.
Comment 20 Parag Nemade 2009-01-09 06:32:23 EST
any updates here or am I supposed to provide some more input?
Comment 21 Parag Nemade 2009-01-13 03:01:29 EST
Ping? Need to have this fixed before F11 Alpha freeze.
Comment 22 Parag Nemade 2009-01-19 02:59:20 EST
ping?
Comment 23 Chris Lumens 2009-01-19 11:02:06 EST
Since this doesn't require any new keyboard layouts defined, I believe it's all handled in the patch to anaconda that I just pushed.  This should therefore be fixed in the next build of anaconda.

Note You need to log in before you can comment on or make changes to this bug.