I noticed following that, the same "Banner saved successfully." appears on the frontend with the article itself under the title

There are even other weird translations in the en-US language so maybe they are a crowdin bug?

COM_ACTIONLOGS_CONFIGURATION="Kullanıcı İşlemleri Günlüğü: Seçenekler"
COM_CHECKIN_N_ITEMS_CHECKED_IN_ONE="Item checked in."

@HLeithner @wilsonge
As can be seen above the US language pack is broken they have even changed the KEY

There are more issues. People dont seem to know how to tell the time in PHP... :-) Incoming.....

I dont have tje language skills to check other language files but the en_US is very weird
and broken

#35207

COM_CONFIG_FIELD_FLOC_BLOCKER_DESC="Отправлять запрет на поддержку отслеживания с помощью метода FLoC в заголовке."
COM_CONFIG_FIELD_FLOC_BLOCKER_LABEL="Блокировать FLoC"

%H:%M:%S is the wrong time... in all the packs I looked at (GB US AU)

- DATE_FORMAT_CALENDAR_DATETIME="%Y-%m-%d %H:%M:%S"
+ DATE_FORMAT_CALENDAR_DATETIME="%Y-%m-%d %H:%i:%s"

I think there is flexibility to update the keys for certain keys like for numbered items for languages where plurals are interpreted differently

there is some flexibility but not for using Russian

@conconnl can you have a look at crowdin, can't believe that Patrick accepted an Russian translation for en-US

https://joomla.crowdin.com/proofread/b2a99ed5361a855bf12c46fc7ced2775/3908/en-enus/90?filter=basic&value=3#q=COM_ACTIONLOGS_CONFIGURATION

github is joking too:

It seems @particthistle did approve it, but probably by accident. There are 12.000 strings too check and process and we are all human.

I'm going through all strings and will delete every non-English translation in US

but does crowdin let you change the KEY as well as the value?

can I suggest it is unpublished for now as some of the errors will cause problems for users.

happy to spend some time helping fix it

but does crowdin let you change the KEY as well as the value?

Nope, it doesn't allow to change keys by users.
They are also updated everyday automatically from the joomla-cms repository.
Unless the files in the source are changed on key level, nothing changes.

JLIB_FORM_FIELD_INVALID_VALUE="Eyetest_THIS_VALUE_IS_NOT_VALID"

lol

Resolving at the moment and updating language pack shortly.

I had noticed a few odd ones had snuck in along the way during proofreading but these ones escaped me in the bulk checks. I’d translated 70% of it myself so had high confidence.

Not sure what you are trying explain with the image.
I see on the left site strings which end with _0 and _1
On the right _ONE & _OTHER.
Which are both correct methods

See localise php

The packages in J3 also use:

Not sure what you are trying explain with the image.

you wrote

Nope, it doesn't allow to change keys by users.

Still correct....
Users cannot change the keys.
The _ONE and _OTHER (and a few others) is an automated thing created many years ago for the plural working of all those variants in the different languages, this is how it also works in J3.

• en-GB error may have been in core string.
• en-AU and en-US were then a copy at that specific point in time.
• At the time I translated them, the date string did not have the code highlighting on it to indicate to translators "Don't change this one"

en-AU and en-US 4.0.0.2 versions being uploaded shortly.

New packs will fix #35204 #35205 #35208

en-AU 4.0.0.4 and en-US 4.0.0.4 released resolving issues.

• Dates have been left as previously formatted in regards to #35208 - issue is not with the language string specifically.

• Menu item configuration:
  

• FLoC:
  

Other strings:

• JLIB_FORM_FIELD_INVALID_VALUE
• COM_ACTIONLOGS_CONFIGURATION

For en-AU the only change was correcting the case on G'day as was pointed out in last night's Joomla Australia meetup.

@conconnl can you have a look at crowdin, can't believe that Patrick accepted an Russian translation for en-US

https://joomla.crowdin.com/proofread/b2a99ed5361a855bf12c46fc7ced2775/3908/en-enus/90?filter=basic&value=3#q=COM_ACTIONLOGS_CONFIGURATION

All good now comrades ? Issue can be closed.

For future language correction suggestions when found, go to Crowdin and add them as suggestions in the corresponding language pack. Proofreaders for that language will then see the crowdsourcing suggestion.

I noticed one other thing here on the pack, in options when setting Yes/No, it displays as Yes/Notice

JNO is wrong in en-US indeed

[...]
JNEXT_TITLE="Next article: %s"
JNO="Notice"
JNONE="None"
JOFF="Off"
[...]

Another issue.

Edit breadcrumbs on frontend

en-GB is right:

en-US is wrong

Another one - edit user -> basic settings tab, several issues on this tab

en-GB

en-US

Such issues should be raised to the correct Translation Team (either on Crowdin or per direct contact). It shouldn't be handled here as it is not core.

Regarding the plural suffixes in the KEYs. That was always the case that the language pack can specifiy whichever suffix they prefer. They can even support multiple notations.
Crowdin always automatically creates the suffixes based on the ICU syntax (ONE, FEW, MANY, OTHER, ...). This is actually a good thing and our en-GB source is a bad example. ?
So this is why you see different KEYs for plural strings. This is and always was expected behavior.

An admin could move the issue if they want too: https://github.com/joomla/core-translations