[BUGFIX] Ensure correct formatting in PHP 8.4 #491
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since php 8.4 the ext-intl class `NumberFormatter` expects a strict locale string and throws a `ValueError` if the given value cannot get parsed. Together with the `uc` of TYPO3, which holds the backend language for the currently logged-in user, this could be set to `default`, which is no valid locale. New TYPO3 instances will write a `uc['lang']=''`, if the person uses `englisch`, which is the default, but older used to write `us['lang']='default'`, which is still correct. This throws the `ValueError` if the NumberFormatter should format with this setting. Introduce the `Locales` class as a constructor argument to the `UsageService` and use the static methods converting the given uc-value to a correct language string ensuring NumberFormatter doing his job. Fixes #486
calien666
force-pushed
the
bugfix/issue-486
branch
from
cbc3362 to
cf71618
Compare
calien666
added a commit
that referenced
this pull request
Sep 21, 2025
Since php 8.4 the ext-intl class `NumberFormatter` expects a strict locale string and throws a `ValueError` if the given value cannot get parsed. Together with the `uc` of TYPO3, which holds the backend language for the currently logged-in user, this could be set to `default`, which is no valid locale. New TYPO3 instances will write a `uc['lang']=''`, if the person uses `englisch`, which is the default, but older used to write `us['lang']='default'`, which is still correct. This throws the `ValueError` if the NumberFormatter should format with this setting. The Locales usage is not used here (other than on #491), as TYPO3 11 does not provide the necessary functions here. Fixes #486
sbuerk
pushed a commit
that referenced
this pull request
Sep 23, 2025
Since php 8.4 the ext-intl class `NumberFormatter` expects a strict locale string and throws a `ValueError` if the given value cannot get parsed. Together with the `uc` of TYPO3, which holds the backend language for the currently logged-in user, this could be set to `default`, which is no valid locale. New TYPO3 instances will write a `uc['lang']=''`, if the person uses `englisch`, which is the default, but older used to write `us['lang']='default'`, which is still correct. This throws the `ValueError` if the NumberFormatter should format with this setting. The Locales usage is not used here (other than on #491), as TYPO3 11 does not provide the necessary functions here. Fixes #486
sbuerk
approved these changes
Sep 23, 2025
sbuerk
pushed a commit
that referenced
this pull request
Sep 23, 2025
Since php 8.4 the ext-intl class `NumberFormatter` expects a strict locale string and throws a `ValueError` if the given value cannot get parsed. Together with the `uc` of TYPO3, which holds the backend language for the currently logged-in user, this could be set to `default`, which is no valid locale. New TYPO3 instances will write a `uc['lang']=''`, if the person uses `englisch`, which is the default, but older used to write `us['lang']='default'`, which is still correct. This throws the `ValueError` if the NumberFormatter should format with this setting. The Locales usage is not used here (other than on #491), as TYPO3 11 does not provide the necessary functions here. Fixes #486
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since php 8.4 the ext-intl class
NumberFormatterexpects a strict locale string and throws aValueErrorif the given value cannot get parsed.Together with the
ucof TYPO3, which holds the backend language for the currently logged-in user, this could be set todefault, which is no valid locale. New TYPO3 instances will write auc['lang']='', if the person usesenglisch, which is the default, but older used to writeus['lang']='default', which is still correct.This throws the
ValueErrorif the NumberFormatter should format with this setting.Introduce the
Localesclass as a constructor argument to theUsageServiceand use the static methods converting the given uc-value to a correct language string ensuring NumberFormatter doing his job.Fixes #486