Skip to content

Fix Linux locale matching and add pt aliases - #968

Closed
Augusto Pinto (alghostzx) wants to merge 2 commits into
microsoft:mainfrom
alghostzx:fix-linux-locale-matching
Closed

Augusto Pinto (alghostzx) wants to merge 2 commits into
microsoft:mainfrom
alghostzx:fix-linux-locale-matching

Conversation

@alghostzx

Copy link
Copy Markdown

The binary was compiling with portuguese brazilian locale by default, but wasn't acessible in any way thanks to this little typo I found, I fixed it, hope it's okay. ;)

Summary written by AI

This PR addresses two issues with locale resolution on Linux environments:

  1. Linux locale separator normalization:
    In crates/edit/src/sys/unix.rs, preferred_languages previously replaced underscores (_) with hyphens (-). However, the internal build generator sanitizes and matches against identifier patterns using underscores (pt_br), causing common POSIX locales like pt_BR.UTF-8 to be transformed into pt-BR.UTF-8 and subsequently fail the prefix match against LANGUAGES. Swapping the replacement direction restores expected matching.

  2. Portuguese aliases in edit.toml:
    Added pt and pt_br aliases pointing to pt-br in [__alias__], ensuring users with generic LANG=pt fall back gracefully to the bundled Portuguese translation.

@alghostzx Augusto Pinto (alghostzx) left a comment

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

@microsoft-github-policy-service agree

@alghostzx

Copy link
Copy Markdown
Author

@microsoft-github-policy-service agree

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I feel like this reverts an intentional change we made to address this exact case.

Edit expects the format of the LANG environment variable to follow the rule laid out in IEEE 1003.1 (so, POSIX):

If the locale value has the form:

language[_territory][.codeset]

it refers to an implementation-provided locale, where settings of language, territory, and codeset are implementation-defined.

That is, it comes to us with an underscore. We transform it to contain a -. We should not accept an invalid LANG and then transform it to something that edit internally knows not what to do with.

@alghostzx

Augusto Pinto (alghostzx) commented Sep 30, 2026 •

Copy link
Copy Markdown
Author

Thanks for the clarification, Dustin L. Howett (@DHowett)! That makes total sense regarding IEEE 1003.1 / POSIX and normalizing to the BCP 47 convention (pt-BR -> pt-br) used by the translation tables.

I will revert the change in crates/edit/src/sys/unix.rs to keep the original _ -> - transformation intact, and keep only the aliases in i18n/edit.toml so that general pt locales fall back cleanly to pt-br.

I will update the branch shortly!

@alghostzx

Copy link
Copy Markdown
Author

I reverted the change in crates/edit/src/sys/unix.rs so the original _ -> - transformation remains intact, and kept the aliases in i18n/edit.toml so that general pt locales fall back cleanly to pt-br.

Just pushed the update!

@lhecker

Copy link
Copy Markdown
Member

So, what is the actual LANG value for which this app failed for you?

@alghostzx

Copy link
Copy Markdown
Author

So, uh, funny story...
I can't reproduce my own error anymore...
Apparently I'm trying to fix a bug that was already fixed... It's present in the stable released version, but apparently in the git nightly in case I compile MASTER today, it's not there anymore. So, uh, sorry for your wasted time and thanks for being so patient. 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants