Skip to content
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

Made L10n.tr not use bare strings as formats. #1038

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

grigorye
Copy link

@grigorye grigorye commented Jan 30, 2023

  • I've started my branch from the develop branch (gitflow)
    • And I've selected develop as the "base" branch for this Pull Request I'm about to create
  • I've added an entry in the CHANGELOG.md file to explain my changes and credit myself
    (or added #trivial to the PR title if I think it doesn't warrant a mention in the CHANGELOG)
    • Add the entry in the appropriate section (Bug Fix / New Feature / Breaking Change / Internal Change)
    • Add a period and 2 spaces at the end of your short entry description
    • Add links to your GitHub profile to credit yourself and to the related PR and issue after your description

This addresses #1039, by introducing a specialized variant of tr for argument-less calls used with wrappers generated for bare strings. Beware that this is a breaking change for the cases where %% had to be used before in bare strings.

@grigorye grigorye force-pushed the bug/Bare-Strings-Used-As-Formats branch from fbe8e26 to 0e50a8b Compare January 30, 2023 14:18
@grigorye grigorye changed the title Fixed L10n.tr to not use bare strings as formats. Made L10n.tr not use bare strings as formats. Jan 30, 2023
@grigorye grigorye marked this pull request as ready for review January 30, 2023 14:21
@djbe
Copy link
Member

djbe commented Mar 15, 2024

I should add this to some sort of frequently asked questions. Do a search through the issues/PRs, and you'll find multiple discussions about this.

The big problem with not formatting strings for those with no parameters, is that it creates a double standard for encoding percentages:

  • For strings with parameters, if you to "print" the string 100%, you'll need to provide the string 100%%.
  • For strings without parameters, you'll need to provided the string 100%.

We do not want our users to have to deal with these inconsistencies. There's unfortunately no good solution for this 🤷 What we usually recommend is providing your own lookupFunction (see the docs), and do a check for no/some parameters. Or a custom template.

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.

None yet

2 participants