I have tested this item ✅ successfully on 6dd7e1c

Thank you!

ideally it should be transliterated, but an exception also enough for quick fix :)

It can't be if you are missing the PHP extensions to actually do that!

It can't be if you are missing the PHP extensions to actually do that!

It is still possible, we actually doing it for an alias field,
However it does not cover everything, mostly only for installed languages that provide transliteration in their localise.php

and

upd, example for uk-UA localise.php:
https://github.com/Joomla-Ukraine/uk-UA/blob/88ca9b96a3872de4e4971315d24465ee9b78b5e0/uk-UA_3.x/language/uk-UA/uk-UA.localise.php#L100-L109

for j4, the priority for the alias as well as for upload image, is:

1 intl extension
2 language pack custom transliteration.
3 for alias only, if no ascii, the date of saving

Well if that case the CMS should be cleaning up the file name before asking the File library to write the file.

The CMS File library is not the place to be injecting lots of language specific code.

File::makeSafe is not the place for language pack transliteration.

Replacing a failed makeSafe with todays date would be worse in my opinion - someone attempting to rename a file, only for that file to not be renamed to what they asked, but to a date... is likely to confuse.

File::makeSafe is not the place for language pack transliteration.

Correct.

Here we have LocalAdapter::getSafeName().

Additionally, the same issue may affect all methods in LocalAdapter, not only move():

createFolder()
createFile()
copy()

Maybe you better move an exception in to LocalAdapter::getSafeName() method,
Ideally add transliteration there also :)

$lang->transliterate('МИМИМИМИ') also returns a blank string...

I have added the exceptions in the LocalAdapter makeSafe, and added language transliterate with another check as both File::makeSafe and $lang->transliterate('МИМИМИМИ') can return a blank string.

I've updated the branch to latest 4.0-dev to get rid of the unrelated javascript-cs error in drone.

@Kostelano Could you redo your test? The PR has meanwhile received some change beside that branch update. Thanks in advance.

So, it works a little differently than I expect.

I just take a file with a Latin name and try to ADD Russian letters to its name. I receive an error NOT declared in the PR, but already another one.

If I try to rename the file to a Russian name WITHOUT a combination with Latin names, I will already get the declared error.

It seems to me that both cases should somehow correspond to the same error.

Also, note that errors are duplicated on the same page, similar to the error reported at #33450.

If a file exists with just the latin chars, then that is correct, as makeSafe will remove the russian and leave the other chars (if your server doesn't have iconv/intl installed)

I have tested this item ✅ successfully on cee7960

I have tested this item ✅ successfully on cee7960

Ok, the main issue is solved by this PR. Thank you!

RTC

Thanks!