> > The changes to HELLO do more that the above says. I don't think I > understand the reason for the change in the "South Asia" line. The South Asia line was correcting the Odia greeting, which I had changed previously (from "Listen" to "Namaskaar") This is unrelated, and I see no reason to rename the variable in a > backward-incompatible way. It's just a variable, so it doesn't have > to be named rigorously correct. If we were discussing new code, the > correction would have had its place, but not now, 16 years after it > was introduced. > This variable name is somewhat misleading. When I searched "iso 638", online to see whether the language codes were updated or not, it showed me results for oven boards, later when searching "iso 638 languages" I realized that the correct standard number is 639. There was also a FIXME above it, so I fixed that. If there is a backward-compatible way to change it please tell me, or if you still feel the change is not warranted, I will revert this it. I don't think we should rename variables and functions. It's just a > lot of hassle for us (defalias etc.) and potentially for others, and > the gain is very small. This variable doesn't even say "oriya", just > "ori". Let's not be too radical here. > Then I should only rename in etc/HELLO, and in (set-language-info-alist) of lisp/language/indian.el. We cannot rename an input method we had for almost 20 years. If there > is some way of having an alias for an input method (I don't think so, > but maybe I'm missing something), let's use that; otherwise we will > have either to leave the old name alone or define a new input method > that is an exact copy of the old one, except for the name and the > mode-line indicator. > How about I make a new Odia input system, just like the ones which I had made for the other scripts, and leave the old ones alone? On Wed, May 18, 2022 at 6:18 PM Eli Zaretskii wrote: > > Cc: 55493@debbugs.gnu.org > > From: Visuwesh > > Date: Wed, 18 May 2022 09:57:56 +0530 > > > > I think we should include the bill link in the commit message for future > > readers. > > We could point to that in the commit log message. >