Subject: Re: bug#75448: [PATCH] Fix documentation of Iroquoian input methods

From: Eli Zaretskii <[email-masked]>
Date: Sat, 11 Jan 2025 11:50:03 +0200

> From: Kierin Bell <[email-masked]>
> Cc: [email-masked]
> Date: Fri, 10 Jan 2025 13:11:17 -0500
> 
> One insight that she provides is that she uses 'Onyotaʼa:ká:', an
> orthographic variant of 'Onyotaˀa·ká·'. The latter is common in
> dictionaries and academic writing, but it would be pronounced exactly
> the same.
> 
> She relates another very important point about avoiding language mixing
> (preserving dialect and orthographical differences) and aiming for
> consistency in orthography within each community.
> 
> The orthography used in my patch, 'Onʌyote’a·ká·', appears to be
> representative of different dialect variant, with a different
> orthography to represent vowel lengthening. But it appears to be the
> most common orthography used by language programs from communities in
> Wisconsin, NY and Ontario, Canada (going by community resources from
> classes that I myself have taken).
> 
> So, what I would like to suggest, if we can practically accommodate it,
> would be to list both of these two forms whenever one would be used,
> e.g.: 'Onʌyote’a·ká·/Onyota’a:ká:'.
> 
> The most important place where the endonym occurs from a user-standpoint
> is in the initial line of the docstring for the `oneida-postfix' input
> method, which is also displayed as completion metadata for
> `set-input-method'. I don't think that this would make that line too
> long in this case, but that is what had prevented me from suggesting
> this type of approach earlier.

I'm okay with this, so please show a patch to make these changes.

> Another issue is that there are orthographic variants in relatively
> common use for the Mohawk and Onondaga endonyms. These are purely
> orthographic and do not represent actual dialect differences as in the
> Oneida case, but if it can be done for Oneida, a similar combined
> endonym listing in docstrings for these input methods would make sense
> for consistency, as well.

Sure, let's do that as well.

> >> There is also a small fix for an incorrect input key given in one of
> >> the input method docstrings.
> >
> > I agree that factually the input method behaves as you describe in
> > your patch, but is it not more reasonable to change the code to behave
> > as the documentation says?  Why should '-' after 'n' produce ñ?  It
> > sounds like using '~' for that is better mnemonically?
> >
> 
> The only issue that I take with using '~' over '-' is that it is quite
> unergonomic to enter this repeatedly (at least on a QWERTY keyboard).
> However, if the convention used by other input methods is to prioritize
> mnemonics in cases like this, then I would be in favor of changing this
> in the next version of the patch.

I agree with Stefan that having both variants is the best.

Thanks.