Modified title to fit user is asking for new feature.

Seems a sensible requirement to me and I am surprised this doesnt already happen

Alas, it is not as simple as some people may think.
Basically, until now and proven false, we can't load multiple languages at the same time for a specific client.
The display of a specific item in the frontend of a multilingual site depends entirely on the language loaded. And evidently the UI will be in that language.
Therefore, even if we were loading the article edit form in a special modal, and in the current state of core code, I doubt that we could load a different language for the modal.

I do not deny it would be nice to have, but I am not surprised we don't for now.

The only possibility I see would be to code as we do for edit menu items in frontend, i.e. redirect to the article edit in backend (where the same user has access and using her/his preferred language).

@infograf768 this should be as simple as changing the URL here:

The question is whether suggested behavior is correct. Default language does what it says - sets the default language on login. If you're editing an article in another language, it's probably because you used the language switcher. Changing this behavior would ignore the fact.

Sorry, I do not understand what you suggest.

Administrator prefered language is ignored... And Edit content is different to View content. When you select a french article in backend the ui does not switch to french because it makes no sense. Why should it switch in Frontend?

Frontend uses language filter. Backend does not. Implementing this feature would go against the concept of language filter.

But how can I edit a persian article in frontend, when I don't understand persian? Possible to switch language in edit window at least? @SharkyKZ

Nope. Not on a multilingual site where language filter is enabled. As its name implies, it filters by language, for the items displayed and ALSO for the UI, as already explained to you.

If your Persian article is tagged to ALL languages (as well as its category as that is always better) and you have a specific menu item present in YOUR preferred language to display that article (or category), then you can edit the article with your language UI.

That menu item (tagged to YOUR language) may have a specific access defined for a certain type of users in order to display the articles from that category only for these users.
Evidently, as that category (and therefore that article) needs to also be displayed when switching to Persian, you will have there another menu item tagged to Persian with whatever the access you want, including public.
But be aware that it is impossible to create associations when an item is tagged to ALL languages.

But how can I edit a persian article in frontend, when I don't understand persian?

How can you edit Persian article anywhere if you don't understand Persian? ?

Possible to switch language in edit window at least?

That's possible by adding a link with changed language to the same page.

I think the problem is not understood.
language filter should be for viewing the page, that is good and correct. But to edit something is an administrator task. Administrator tasks should have administrator language for the UI. When translator sends me a file to change on page abcdefg and I edit pae abcdefg in frontend it should be in my favorite administrator language. That is the only logic way.

I understand your request and it seems sensible to me. @infograf768 points out that it is not a simple change.

It's not a simple change and you really should use the backend for this type of work. TBH, frontend editing has enough issues that I would seriously suggest people avoid it for anything more than a quick (emergency?) fix; use the backend interface that has the proper interface and workflow for this type of work and leave the frontend for displaying data.

Thats an unbelieveable suggestion @mbabker - I cannot believe you sell your websites to your clients like this. I am really shocked. Frontend edit is never an emergency - It should be actually the default and backend the emergency. Joomla is so much behind in sense of UX. No wonder people change to other systems where frontend editing is working fantastic.

If you're talking about a frontend in-context style editor (i.e. a page builder), then yes, that is a better solution. Joomla's frontend editing is not an in-context editor; it's a "standard" form wrapped in your template's design. Our frontend editing is feature incomplete in relation to the backend and behaves quite differently in relation to the backend editing workflow. It might be OK for simple content edits, but I would never suggest that it be the primary edit interface for anyone.

I cannot believe you sell your websites to your clients like this

At the agency I work for, no client who is using a off-the-shelf CMS has a frontend editing solution available to them (if they want to guess the links to log into the frontend and get to the frontend editing interface in the case of Joomla, more power to them, but they will be met with a broken screen because our non-Bootstrap 2 based templates were not designed to render those edit pages). All of them who do their own content management use the CMS' administrative interface.

other systems where frontend editing is working fantastic.

Do they have built-in multi-language support for both
built-in and 3rd party content extensions similar to the capabilities of Joomla ?

And then are there any good free 3rd party extensions to achieve similar capabilities as Joomla ?
you need subscription cost, just to achieve multi-language, i mean it is a feature that should be built-in

And about these 3rd party, do have a performance that scales with website size !?
or it becomes from terrible to just "acceptable" with a fast server ?

Joomla multi-language features scale excellently !

You really all don't see it does not make sense to show another language in editor - I give up...

Your issue is clear. The fix for it is not a simple one because the behavior you're looking for conflicts massively with the multi-language routing system. Whereas, it behaves correctly in the admin because the admin area does not have a concept of multi-language routing to work against, it is based entirely on user parameter.

@B3nito

i did not say that this is not an issue, but want to clarify the following

you are navigating website in Persian

1. thus you can see the Persian articles in a multi-language enabled website
2. and then you click to edit 1 of them and the interface should change to user default language ?

this automatic change is indeed useful for some users,
but it is a little strange, because current user has already selected that frontend language is Persian

i mean i understand your argument but for some users this automatic UI language change will feel like a bug, because they have already selected persian language as current language

PS
i have just tested
if you

1. comment out this in the article model
   //$this->setState('filter.language', JLanguageMultilang::isEnabled());
2. and you also set any language to the Edit URL link,
   e.g. if you set the default language of the current user

then it works as you suggested
Maybe we could have 2 options in the drop down

Edit
Edit in my language

also, do not forget RTL/LTR .

Base on the discussion above, I'm closing this issue. Anyone needs this behavior can try to apply code modification suggested at #22517 (comment) or #22517 (comment) .