[#35681] - [4.0] Fix language strings causing false plurals in crowdin
- Fixed in Code Base
- 5 Oct 2021
- Medium
- Build: 4.0-dev
- # 35681
- Diff
- richard67:4.0-dev-fix-language-string-wrong-crowdin-plural
User tests: Successful: Unsuccessful:
Pull Request for infograf768/j4localise#30 (comment) .
Summary of Changes
Language string constants ending with "_ONE" seem to trigger some kind of plural string generation for translations on Crodwin.
See infograf768/j4localise#30 (comment) .
To avoid this, we should not use language string constants ending with "_ONE" if they are not really plural strings.
Work in Progress (WiP): I have to complete testing instructions.
As soon as ready, I'll remove draft status from this PR.
Testing Instructions
Hint: It needs to run "npm ci" or "npm run build:js" after having applied the PR.
- Code review: Check if there are language strings in the CMS core having a key ending with "_ONE".
- In content history modal of some content having some history (i.e. more than 1 version), use the "Preview" button without having selected any version.
Hint: You can use that button even if it visually appears to be disabled. But that's another issue to be solved with another PR. - In the same modal, use the "Compare" button with only one version selected.
- Create a module of type "Tags - Similar" and check the available options in the "Match Type" drop-down on the first Tab "Module".
Actual result BEFORE applying this Pull Request
-
Strings "COM_CONTENTHISTORY_BUTTON_SELECT_ONE" and "MOD_TAGS_SIMILAR_FIELD_ONE" found.
- Options "All", "Any" and "Half" are available.
Expected result AFTER applying this Pull Request
-
None.
-
Same as without this PR.
-
Same as without this PR.
-
Same as without this PR.
Documentation Changes Required
None.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_content com_contenthistory Language & Strings JavaScript Repository NPM Change |
You might need to check MOD_TAGS_SIMILAR_FIELD_ONE
@brianteeman Yes, that's the one I wanna check. Do you think I should do them all in this PR, or should I better make separate PRs?
if you are fixing the same problem then you can do them in the same pr. its a small enough a change
@brianteeman Are you familiar with CrowdIn? I'm not. Do you know if it would be ok to change "MOD_TAGS_SIMILAR_FIELD_ONE" to "MOD_TAGS_SIMILAR_FIELD_ANY", or do you have an idea why it hasn't been named like that from the beginning on? Does ending with "_ANY" cause similar issues on CrowdIn? Or can we use that?
Answering no and no idea to each question - sorry
@brianteeman Other question: Do you know if it's still ok to have the deprecation comment above the line with the language string? Or should that be put to the end of the line with the string?
"MOD_TAGS_SIMILAR_FIELD_ONE" to "MOD_TAGS_SIMILAR_FIELD_ANY", or do you have an idea why it hasn't been named like that from the beginning on? Does ending with "_ANY" cause similar issues on CrowdIn? Or can we use that?
Some languages may use ANY in their plural forms and crowdin may wonder there.
I suggest: MOD_TAGS_SIMILAR_FIELD_ONE_TAG
| Labels |
Added:
Language Change
?
NPM Resource Changed
|
||
| Category | Administration com_content com_contenthistory Language & Strings JavaScript Repository NPM Change | ⇒ | Administration com_content com_contenthistory Language & Strings JavaScript Repository NPM Change Modules Front End |
Wont the plurals still be generated as they are still in the language file?
Wont the plurals still be generated as they are still in the language file?
@brianteeman I think so. But what else can we do? We're not allowed just to remove the strings, are we?
The arguments for not removing them was always something I did not agree with. It was so that you could use an old and outdated language file with the very latest version of joomla and/or in case the string was used by an extension which is unlikely to apply in this case.
The problem is that if you dont remove the strings then you aren't solving the problem (are you?)
The problem is that if you dont remove the strings then you aren't solving the problem (are you?)
@brianteeman I solve the problem ... for Joomla 5.0.
@wilsonge Do you know what we shall do? Can we remove these strings?
I would just remove them as we're fixing a bug.
And chances are slim that the string is used by 3rd party.
I have tested this item
Doesnt fix the problem
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35681.
@brianteeman l’ll update this PR tomorrow.
| Title |
|
||||||
I've changed this PR so the bad strings are not deprecated but removed.
@brianteeman Please test again. Thanks in advance.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35681.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35681.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35681.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-10-05 14:29:57 |
| Closed_By | ⇒ | bembelimen | |
| Labels |
Added:
?
?
|
||
Thx
Thanks all.
You might need to check MOD_TAGS_SIMILAR_FIELD_ONE