On 10 July 2018 at 09:45, Pander <pander@users.sourceforge.net> wrote:
On 07/10/2018 10:34 AM, Paul Moore wrote:
... Is this a Unicode Consortium standard, or a 3rd party project? The website wasn't completely clear on the matter, but there's nothing I could find on the Unicode website about translations of the standard name (there's also nothing that specifically explains the choice to use English for the standard names...). If it's not part of the standard, then there's an argument that the Python implementation of this should also be a 3rd party package, rather than being in the stdlib. Is this feature available on PyPI at the moment?
This is a third party initiative. The translations are contributed by volunteers. I have talked with Python core developers and they suggested to post this here, as it is for them out of scope for Python std lib. At the moment there is no implementation yet. That is what I would like to discuss here.
Thanks for the clarification. I'd say that in that case, this should probably be created as a 3rd party project on PyPI in the first instance. If it becomes popular and is useful to a sufficiently large user base, it could then be included in the stdlib. Your example code uses a separate unicodedata_l10n package, and it would be very easy to publish that on PyPI and later move it unchanged to the stdlib if needed.
Also, would this not lead to non-English speakers expecting that the localised names would work in "\N{...}" notation?
Don't know. If an implementation has been made, it should be positioned very carefully.
Having this as a 3rd party project would make it much less likely that users would expect \N support, IMO. Paul