Skip to content

gh-87281: Improve documentation for locale.setlocale() and locale.getlocale() #137313

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented Aug 1, 2025

@serhiy-storchaka
Copy link
Member Author

Reference to RFC 1766 was incorrect -- RFC 1766 specifies language and territory separated by a minus instead of underscore, and it does not contain much useful information anyway. Also, getlocale() returns the language code in other format on Windows and some other platforms.

getlocale() does not return code "C", it returns (None, None) for the "C" locale.

Added specification of universally accepted formats. Late @modifier will be added for the language code. This will be made less vague when we guarantee these formats.

name using the locale aliasing engine. An empty string specifies the user's
default settings. If the modification of the locale fails, the exception
:exc:`Error` is raised. If successful, the new locale setting is returned.

The format of the *locale* and the language code strings is platform
depended, but the forms ``language[_territory][.encoding][@modifier]``
and ``language[_territory]`` respectively are typically accepted on all
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
and ``language[_territory]`` respectively are typically accepted on all
and ``language[_territory]`` are typically accepted on all

I'm not sure what this is referring to?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It refers to the locale and the language code strings.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is not clear, we can only specify format for locale, and then say that the language code has the same format, but without encoding and modifier (support for modifiers will be added in #137253).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd write: "the form language[_territory][.encoding][@modifier] is typically accepted".

The second version you mention is already included in this.

Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Copy link
Member Author

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your grammar fixes @StanFromIreland.

name using the locale aliasing engine. An empty string specifies the user's
default settings. If the modification of the locale fails, the exception
:exc:`Error` is raised. If successful, the new locale setting is returned.

The format of the *locale* and the language code strings is platform
depended, but the forms ``language[_territory][.encoding][@modifier]``
and ``language[_territory]`` respectively are typically accepted on all
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It refers to the locale and the language code strings.

Copy link
Member

@malemburg malemburg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM modulo the small change requests.

name using the locale aliasing engine. An empty string specifies the user's
default settings. If the modification of the locale fails, the exception
:exc:`Error` is raised. If successful, the new locale setting is returned.

The format of the *locale* and the language code strings is platform
depended, but the forms ``language[_territory][.encoding][@modifier]``
and ``language[_territory]`` respectively are typically accepted on all
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd write: "the form language[_territory][.encoding][@modifier] is typically accepted".

The second version you mention is already included in this.

Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Copy link
Member

@StanFromIreland StanFromIreland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting merge docs Documentation in the Doc dir needs backport to 3.13 bugs and security fixes needs backport to 3.14 bugs and security fixes skip news
Projects
Status: Todo
Development

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy