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:

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?

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.

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.

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.

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.

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.

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.

(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

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.

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.