drone failure unrelated

Why not default to the active language and site client like we did before?

Why not default to the active language and site client like we did before?

Because it was really confusing for the user. We have many forum posts about that issue since the first implementation of the overrides.
With the new select (with a null value), the user will be forced to choose the adequate language/client instead of defaulting to the site default when creating a new override.

EDIT: Basically, it means that we do not have to add a permanent Note in the overrides manager which would say:
Beware, when creating a new override it will create it for the default site language if you have not set the filter to another one.
or, as some say:
Look at docs...

My clients have Usability Issues here too:

1. Why can they create an override for backend and frontend at once from context admin but not from context site?
2. Why isn't it possible to select language and context inside the edit view?
3. Why isn't it possible to search for all language keys inside the search tool?
   Example: A german translation is missing and only available in english. Client has to close the edit view, change the context, go on new, search for the key and copy it, close again, change the context, click on new, paste the key.

A huge improvement would be to select the language and context inside the edit view, just like inside Menuitem edit or Article edit. This would mean that you don't have to filter the context first before editing anything. Would be great if this improvements could be considered.

Would be great if this improvements could be considered.

I have already been thinking at that. :)

This requires an important Refactoring.
In the Manager 2 separate fields, one for client and one for languages ONLY for filtering the manager.
In the edit view indeed ability to select the language and client with the search key
Add the possibility of saving a string for both clients when any client is selected.

It is quite an important change and can't be done fast.
May I suggest that we get this tessted/merged in 3.9 while we try to do the refactoring?

Not sure I understand your 3rd point though.

Would be great, I don't know how to code something like that but would appreciate it a lot.
For my Point 3: Certain Extensions have not complete translations for other languages. English is mostly 100 Percent and German maybe only 90 %.
So someone sees in Frontend a wrong word means a translation is missing or wrong here. But in this situation the user does not know the language key.

1. User goes into the overrides
2. Selects German - Site and clicks on Add
3. Is using the search tool to find the key
4. No key is found because the key only exists in english
5. Is switching to English - Site and clicks on Add
6. Is using the search tool to find the key
7. Is closing the Add View
8. Selects German - Site and clicks on Add
9. Is pasting the language key and translates it correctly

I guess your client is trying to do something which overrides are not designed for.
I try to explain:
Although they can indeed be used to add a missing string for a specific language (if one knows the constant/key) they are mostly meant to override. i.e. replace the value of an existing constant/key in the chosen language.

What your user wants is search for a specific value, not a constant. That one could be in any language installed on the site (think of a multilingual site).
Searching that value for all languages in the override edit could be a long process and may be confusing. Some strings may have the same value than the one the user searches for.

It is much simpler to use the tool which is designed for that: enable debug lang, go to frontend and get the constant there, then in back-end in the override edit view for German (site), paste the key and enter the value desired.
Beware though as a string displayed in frontend may come from a plugin. In that case, if the 3pd dev has done its work almost correctly, the string will start by PLG_ and the user will know the "override" will have to be created in admin client.

EDIT: I do agree though that in both cases, it needs multiple actions to solve the issue.

Yes but for Example the Site shows a string calles "Web" which is completely legal in Germany, but the User wants to change this to "Internet". How should an Enduser know in this situation that Web comes from the english strings? Also it would not make sense to send them to the language debug on a live site. If you can select the language inside the edit view you can easyly switch between the languages without the need to leave this view. It would be solved by the refactoring :)

Yes but for Example the Site shows a string calles "Web" which is completely legal in Germany, but the User wants to change this to "Internet". How should an Enduser know in this situation that Web comes from the english strings?

That is the job of the manager/admin, not of the enduser.

It would be solved by the refactoring :)

Partly yes, if someone helps with some AJAX magic. We are not there yet. ;)

That is the job of the manager/admin, not of the enduser.

hm... overrides are imho a tool for endusers and not for admins. Admins would work with the ini files directly. But thats of course a subjective matter

If they work with the ini files directly then that would be very foolish as they would lose the changes on update

Never heard of lose changes of the override files at updates.

I can't apply the patch, can you help?

@B3nito maybe this didn't work with Patchtester.

@B3nito
This patch is for staging, not 4.0 . ?

I updated to 3.9.0-beta2-dev now I can test.

I have tested this item ✅ successfully on d1fe66e

Tested and it is working like you described @infograf768 - thank you for more overview!

I have tested this item ✅ successfully on d1fe66e

RTC

@mbabker
Can this be merged?