Introduce translated page tree
Currently there is being some work for improving the accessibility of page tree done.
See e.g.: https://forge.typo3.org/issues/86818. This is therefore a great opportunity to jump on this train and continue this process.
There are already several issues in the board, which partially are almost six or more years old.
All these issues describe more or less the possibility to have a translated page tree.
This issue aims to summarize this requests and bundles them to have a good basis for further discussions and considerations.All this requests are based on several drawbacks, the page tree is facing currently:
- A TYPO3 editor isn’t always fluent in the default language which is used for the page tree and therefore the page tree is just useless for him.
Expect the general page structure.
- The page tree live search only considers the default page records (this applies for either searching for title and also for uid).
So it’s currently not possible to filter for localized page records.
- To get the position of a localized page record in the page tree, one has to find it through the top bar navigation,
switch to the default record in e.g. the edit view, copy the uid and afterwards search in the page tree search for the default one.
Only after these steps he is able to edit the localized page record.
To improve the readability I’ll always use the term „language“. But keep in mind that it can actually also be a localization,
because one can add `sys_language` for DE_CH as well as DE_AT.
Introduction of a selection (select box) at the top of the page tree (next to the search / filter) buttons to enable each backend user to select his preferred language.
Obviously in which he is fluent.
This selection should certainly be saved to backend users UC settings. He shouldn’t need to select it again after each login.
The select box will only be displayed if there is at least one `sys_language` record defined.
Furthermore only languages the backend user has proper access rights are displayed in the select box.
- Really obvious but it needs to be defined: Default will be always the default language till a backend user adjusts it by selecting another one.
Or another default is set via UserTSConfig.
- The context menu in the page tree refers to the page record in the selected language.
This means, if a backend user has selected “German” and afterwards hides the page record in the context menu, the “German” record gets hidden.
- Searching / Filtering the page tree will always consider the currently selected language + default records which are not yet translated (See „necessary consideration“ for the reasons).
- Changing the page tree language while searching / filtering is active, the page tree will reload with the „new“ page tree in the selected language and after that also applies the filtering to it.
- A UserTSConfig option will be introduced which allows disabling the language selector for user (groups).
- A UserTSConfig option will be introduced which allows setting a default page tree language for user (groups).
What happens if the page is not fully translated/localized in the selected language?
More specific: What happens when just a parent page is not translated/localized but the child pages are?
A possible solution would be to show the default ones in this case. Furthermore the page title should be in brackets
to give the backend user directly information about this record is yet not translated.
By editing the page title (returning the default title including the brackets) a new localized record will be created.
This possibility should be made public to the backend user via e.g. a tooltip by hovering over the default record.
Step 2 features (TBD)
If the page tree language was switched, hovering over a record should display a tooltip containing the uid and title of the default record.
Updated by Stefan P over 1 year ago
Personally I'd find it OK if always the L=0 tree is displayed, but the editors have the option to also show one L>0 tree "overlayed" (each node is then for example "My page [DE: Meine Seite]" with "[DE: Meine Seite]" grayed out or on a new line or some nice styling like that, maybe also with some indicators if one of the both language is hidden), if no overlay is existing for a page in the choosen "bonus language" only the L=0 title is shown, obvisouly.
The filter/search should always search in all languages (because it must work for all editors in all languages and editors must be able to find a page by translation because they may only know the translated title).
Alternativly one could think about allowing the selection of multiple/all language showing the tree - the question then is: how to style the tree nodes so that the tree structure is still "readable"?
Updated by Michael Telgkamp over 1 year ago
Some thoughts of Rachel on this topic:
Let's imagine a site in English (default language), Spanish, French, and in German. A translator who is fluent in English and Spanish will have both languages set in his permissions. He will translate the pages from English into Spanish. The first time he arrives on the site that has not yet been translated, the tree structure is in English. In the page module there is a drop-down list in which he selects "languages". Today you can only select one language or default. Either we have all languages, or we have the default language + the chosen language. It would be interesting to be able to choose a language "from" and a language "to". This way we would have two columns for the translation we are working on, and the page tree could be consistent with this choice: the pages title would be in the translated language, and if it is not translated the "from" language.
For a translator who can translate from German into French, he must work on pages already translated into German. So in the page module, he selects from German and to French. In this case, in the page tree, the titles are in German, if they are translated into French they are in French, and for pages that do not yet have a German version, the titles are in English and greyed out to show that he cannot work on them yet.