m17n-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [m17n-list] Add arrows


From: Vish vas Vasuki
Subject: Re: [m17n-list] Add arrows
Date: Wed, 9 Oct 2013 20:36:07 -0700


On Wed, Oct 9, 2013 at 8:08 PM, Anubhav Chattoraj <address@hidden> wrote:
I don't see what any of this has to do with purported ITRANS/Optitrans standards or who wrote what file. It's simply about not adding idiosyncratic characters to the central copy of the file.

The source of Satish's confusion is clear - he expects to see conformance to ITRANS in a file named *-itrans.mim despite the fact that the file in question has deviated from the standard long ago, and despite being informed that such is the case.

It is good to resolve this once and for all. Fork. Restore hi-itrans to adhere to ITRANS.
 

Satish needs to input « », Vasuki needs to input →, a lot of other users might need to input other special characters.
No - as far as I understand, Satish has no need to input it  « » - he just made up a story just to make the point you are making here.
 
There is no way to balance all these idiosyncratic requirements in a single input method.
There is no need to balance in this case : - /> is not mapped to anything else. It is just some unreasonable fear of bloating a file that is stopping this.
 
The fact that the proposed character is used by the community of Sanskrit students doesn't invalidate this argument; there are plenty of field-specific symbols used by English-speaking mathematicians, linguists, architects, engineers, cartographers etc, but no English input method tries to accommodate all these symbols, nor is it expected to.

Users who really need to input idiosyncratic characters can always use the associated Compose key sequence. Of course, they can also modify their .mim files individually, but non-technical users might hesitate to do that.
 
This "my input method does this, users of XYZ community can go modify files on their own if they care" approach is not one that I agree with.

"Users first, engineering convenience second" is what I want. That is what makes great, fun to use products.
 
(An aside: Seeing as the → symbol is mostly used by Sanskrit students/grammarians, one could argue that it's common enough in Sanskrit writing to merit inclusion in sa-itrans.mim. I can't weigh in on that either way, but I still fail to see why the change is proposed on a *Hindi* input method when a Sanskrit equivalent alreay exists.)

Much Sanskrit grammar is discussed in hindI.


--
--
Vishvas /विश्वासः


reply via email to

[Prev in Thread] Current Thread [Next in Thread]