On 2021-02-08 17:07, Robert Elz wrote:
Date: Mon, 8 Feb 2021 14:28:24 -0800 From: Guy Harris <gharris@sonic.net> Message-ID: <90554020-92B9-46CA-83DF-AC914E612DBE@sonic.net>
| None; the issue is that the city names are *English-language* city names,
Yes.
| and should reflect the most common English-language transliteration | of non-English-language names.
But not that.
English names (whatever they are of) do not need transliterating into English, they already are. For some places English uses what are (effectively) transliterations of the local name, for others, the name isn't even similar Bangkok's name in Thai transliterates as Krungthep[MaHa.....] (it keeps going, it is a very long name, but is most commonly abbreviated to Krungthep) (the leading K is pronounced like a G in English). In tz we use Bangkok, as that's the English name.
I don't much care what Kiev/Kyiv is called in English (Kiev is what it has always been to me, and will probably remain that way, but it isn't as if I use the name anywhere other than here). However, the content of recent messages makes it appear that someone has started a campaign ("Please help get the name changed, by sending e-mail to... and in it say ..."). Because of that I am (for now) opposed to making any change at all to this one (and I don't care what Google, or various newspapers, etc, have decided to do). If we start paying attention to this kind of thing we're simply inviting it to happen again. So say, "Sorry, no, your campaign has caused us to decide to retain the current name" and nothing else.
Agreed! One of the most important lessons in developing and maintaining production software is learning to say "No!" sometimes "Hell, NO!" in response to some issues or requests that provide no benefit to the project or product, but may only introduce bugs in the project or product, or downstream. In the commercial world we can say, these parts make sense, and if you want us to do that for you, we estimate it will cost $X00k/$XM to conduct and provide an impact assessment, develop that, change all interfaces, retest, and redeploy the app, site, system, and everything. In the open source world, maintainer effort and time is the cost, as is the impact downstream on other projects, who have to conduct and provide an impact assessment to decide do we want to pass on these changes to our downstreams, or maintain patches to revert them to maintain stability to our downstreams, and do we have that capability if the project has constraints? Given tz downstreams are every major system and vendor in the world, and other projects like CLDR, who have their own release schedules, and possibly contributor or volunteer limits on the time and effort they can provide, stability of *ALL* external interfaces *MUST* be a major consideration. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]