Some contributor's names written incorrectly (in ASCII) in documentation:

Jesús Cea Avión as Jesús Cea Avion
Lars Gustäbel as Lars Gustaebel
Gerhard Häring as Gerhard Haering
Marc-André Lemburg as Marc-Andre Lemburg
Martin von Löwis as Martin von Loewis
Charles-François Natali as Charles-Francois Natali
Žiga Seilnach as Ziga Seilnacht

The proposed patch restores natural spelling (based on Doc/ACKS and Misc/ACKS).

I'm not sure about how to write right: Žiga Seilnach or Seilnacht?

It seems to be the latter: Žiga Seilnacht

http://mail.python.org/pipermail/python-dev/2007-March/071786.html

> It seems to be the latter: Žiga Seilnacht

Then Misc/ACKS should be corrected too.

Is there a reason not to correct that spelling in this issue?  Otherwise, we could create a new issue.

There was a long-standing opposition by Guido to use UTF-8 in that file, and also complaints about legibility. Not sure what the current status is.

It doesn't matter much to me, even though the spelling of my name is affected.

Well, here is updated patch. Also fixed names of Walter Dörwald (was Walter D�rwald) and Martin von Löwis in Misc/HISTORY.

All changed files (documentation, ACK-files, Misc/HISTORY) already in UTF-8 and contains non-ASCII names.

Löwis written as Loewis in some other places: Lib/idlelib/NEWS.txt, Tools/README, source comments. Same for Marc-Andre (without é) Lemburg. I do not think, that it matter in comments, but not sure about NEWS- and README-files.

Thank you for taking the initiative. Regarding use of UTF-8 for text files:

I think we ought to acknowledge that UTF-8 has become the defacto standard
for non-ASCII text files by now and with Python 3 being all Unicode, it
feels silly not make use of it in Python source files.

Regarding my name: I have no issue with the apostrophe missing on the e.
I've long given up using it in source code or emails :-)

To be clear on this issue's scope, I would state in a single comment a white list of which directories or individual files are being corrected (or if necessary, the rules to determine such a list, e.g. any file whose name root is "NEWS", etc).

I would also recommend being systematic about this by creating a script to search the above files, along with a configuration section containing the list of replacements: e.g. correct spelling -> list of misspellings for that name.  And upload the script to this issue.  That way people can see what misspellings have already been accounted for, more could be added easily, and it could be used again if necessary.

Because this may grow in scope (e.g. into source files) and because it affects people's names, it may be worth raising on python-dev.  At the least, people would have the chance to contribute known misspellings.

Make sure that it's still possible to generate the pdf of the docs (with `make latex` and then `make all-pdf` in build/latex/).
Latin1 should be fine, but IIRC non-latin1 will break (sorry Žiga).

Indeed, PDF rendering is important. OTOH, Latex T1 does support Ž. Untested, \v{Z} should generate that character. If this doesn't work, the build process needs to be fixed.

> Indeed, PDF rendering is important. OTOH, Latex T1 does support Ž.

I tried to put a Ž directly in an rst source and indeed the pdf has been created correctly.

All names interpreted correctly except cyrillic (Alexander “Саша” Belopolsky 
and Марк Коренберг). I think it's just because of lack of some non-installed 
package (of course, Latex supports cyrillic).

I basically agree with Marc-André. Indeed, I think Acks, at least, should contain names in native spelling plus, if that is not Latin-based, a romanization. Three reasons:
1. I want English-speaking Python programmers to feel welcome to contribute and be acknowledged with what is visibly their native name.
2. I want people to be able to looks at the contributors list and see that Python is an international project.
3. Transliterations are ofter lossy, and in both directions. Romanizations do not necessarily tell contributors' compatriots how to address them in their mutual native language.

If stdlib .py files are still restricted to romanizations, those could at least be looked up in Acks. But Python does come with an utf-8 unicode editor, Idle, that handles at least the BMP just fine (because tcl/tk does).

The idea also to include a romanization is a good one.

While working on issue 15437, it occurred to me that storing the names in a structured form might come in handy.  This would let us do things like list the username(s) associated with each contributor alongside their name (and access this information programmatically).  And perhaps also include information like the following: http://www.python.org/dev/committers

> While working on issue 15437, it occurred to me that storing the names in a structured form might come in handy.

In a separate discussion, Ezio pointed out a case where we are already scraping data about members from doc files:

http://hg.python.org/tracker/python-dev/file/69984a770ab5/extensions/jnosy.py

So there is another case where we would benefit from storing names with associated attributes in a centralized, structured way.  Sorry if this is a departure from the topic of this issue.  I may create a separate issue for this or raise the idea in another forum.

What about patch review?

The patch looks ok to me so, unless someone is opposed to using utf-8 in the doc files, I think it can be committed in 3.x.

Non-ascii characters already used in a lot (43-50) of doc files.

    LC_ALL=C find Doc/ -type f -name '*.rst' -exec egrep --color "$(printf '[\x80-\xFF]+')" '{}' +

All touched files already contains non-ascii characters (and Misc/HISTORY contains invalid UTF-8 sequence).

New changeset 3654c711019a by Antoine Pitrou in branch '3.2':
Issue #15444: Use proper spelling for non-ASCII contributor names.
http://hg.python.org/cpython/rev/3654c711019a

New changeset 867de88b69f0 by Antoine Pitrou in branch 'default':
Issue #15444: Use proper spelling for non-ASCII contributor names.
http://hg.python.org/cpython/rev/867de88b69f0

Ok, then I've committed the patch. Closing the issue now, thank you.