• The Vector omni language selector seems like a central point where to put an entry point

It doesn’t seem to be actually omnipresent. For example, I don’t see it on https://www.mediawiki.org/wiki/Engineering_Community_Team/Meetings/2013-04-30?useskin=vector-2022. Maybe a link could be added to the actions menu (where e.g. Move lives)?

• after preparing, if they are not an admin

Currently, non-translation admin users cannot use Special:PagePreparation. Maybe it should be opened to everyone?

Do you mean Special:PageTranslation? Special:PagePreparation should be available for everyone.

No, I really mean PagePreparation (e.g. oldwikisource:Special:PagePreparation). Actually, Special:PageTranslation without parameters does work for everyone (it lists the translatable pages).

Oh. I think that as part of the improvements we can make it available for everyone, maybe with some disclaimers that it's not perfect and makes mistakes.

Making a page available for translation (or making it a translatable page) is a two step process:

1. Add <translate> tags to the page
2. Mark the page for translation

Point (1) can be done by,

• Manually by editing the page, and then saving the page.
• It can also be done via https://meta.wikimedia.org/wiki/Special:PagePreparation that adds the <translate> tag and other tags such as <languages />. Special:PagePreparation can work with simple markup, but will probably have issues with existing translatable page.
  

Point (2) can be done by,

• Clicking on the Mark this page for translation that appears after the <translate> tags have been added to the page.
  
• It can also be marked for translation by going to https://meta.wikimedia.org/wiki/Special:PageTranslation and mark the page for translation there.

6. User applies necessary translation settings, and if:
   1. Permitted, the user marks the page for translation.
   2. Not permitted, the process ends here, the page is added to a queue for marking by others in the community.

What do you mean by “necessary translation settings”? If things like enabling translation-aware transclusion or selecting priority languages – those are tied to the process of marking the page for translation, and thus can only be done by “permitted” users (translation administrators). You may want to change this, but this is how the “current user flow” works.

2. Enhance Feature Visibility and Usability: The Wiki platform's size, various visual screens, and the user's different screen sizes all necessitate multiple, visually significant entry points (aside from source editing). It's crucial to ensure ample access points to the tool that are easily found on any device.
   

I’m not sure if putting the same link at multiple places in the page chrome is a good idea – I’d be unsure whether all these links do the same. Repeating the link present in the content (the gray box on the screenshot) in the chrome is okay, but I’d drop one of the two chrome links.

2- The other change comes after publication, in view mode. After a page is published, any editor viewing the page for their first time will see a banner asking the user if they want to mark the page for translation. This banner tells a little bit about the importance and easiness of making a page translatable. The banner will take the editor (the page editor or any other editor with permissions) to the translation settings page.

Unless the current status quo is kept and only translation administrators will count as “editors with permissions”, this is quite obtrusive. Most users want to read pages, not edit them. The Edit tab occupies one line, which is a good balance between being noticeable and not being distracting. This huge banner would be too much. It’s okay to show it to the user who added the <translate> tags directly after saving the page and maybe also to translation administrators, but not to everyone. (On the other hand, opening the settings to everyone would be a good idea: I as a translation administrator have no idea what the priority languages would be; and I as a user who understands the Translate system but doesn’t have translation administrator rights on all wikis, might want to help translation administrators on other wikis by setting whether translations need to be fuzzied or whether translation-aware translation should be turned on.)

The "make page multilingual” toggle is on by default on every new page. If turned off, the user will need to provide a reason why the page is not to be translated into any language

Required reason is something new and likely contra-productive. There are cases that are simply crystal clear: talk pages (there are quite a few in even-numbered namespaces), pages that contain no linguistic content (templates that contain only formatting, pages that transclude all their linguistic content from other templates), and so on. If users are required to provide a reason, they’ll likely type one random character, which doesn’t help others, but makes the process more stressful for that user. Let’s assume good faith: if the user doesn’t provide a reason, it’s because the reason is obvious.

After a page is marked for translation, the page now shows as normal, but instead of having a "translate this page” link above the text, the language selector will play a centralizing role. Being the "place to go” for translations.

What if a translatable page has interlanguage links, like https://meta.wikimedia.org/wiki/Main_Page?

How do you imagine this to work on translated pages? The “Available translations” part would probably look the same as on translatable pages, but currently translated pages have no “translate this page” links (rather the Edit tab is replaced by a Translate tab), so maybe the “Don’t see your language?” part could be hidden there.

Hi @Tacsipacsi, you raised some really important points. Thank you. This is still a concept in progress, some proposals have been shown to the team and engineers but nothing here is decided. That is why we are exploring a few options and trying to change as little as possible. But everything showed here is subject to a LOT of changes still.

Permissions and settings: Every field/form tied to an user permission will need to be revised here. This could also imply rethinking translation permissions for all as you also mentioned.
Multiple entry points together: I do agree that all 3 seem like much, specially so close to each other. The reason is that 2 of them are dismissible (clicking "do it later" on the banner and the hiding the tools menu), leaving only the language selector as always on. I believe we have a lot of improvements to make, such as rethinking the banner to be less intrusive (or getting rid of it) for sure. You are right, casual readers don't want to see this banner, the idea is only to show it to users with necessary translation permissions.
Required reason for not making it multilingual: This was a bold proposal for sure. We are thinking about the foundation's goal to make information accessible to everyone. In the current journey, the user needs to provide a reason why they don't want a page translated into a specific language, so we used of the same rationale for when the user does not want any translation at all. And the idea is for none of them to be blockers (no editor/human needs to approve it). It could work like an "author's comment". So if a different editor wants to mark that page for translation, they could at least read the reason why the original author does not think it should be translated.

Your arguments are point on and we will for sure work on them as this project is far from finished. It is a proof of concept that now needs to consider every detail and variation like the ones you pointed out. Please let's keep discussing these because every single details needs to be aligned and the complexity of it can make us blindsided in some decisions.

Thank you :)

Project Update:

We have proposed a new design strategy that incorporates input from the community and team members. The purpose of these changes is to streamline the user experience specifically in relation to page translation preparation.

Page Creation:

The existing page creation process has been reestablished by the team. Within this system, an editor can write and publish a page without variations as to how it is today. The previously suggested UI and backend modifications have been discarded.

Post Page Publication:

Under the proposed changes, once a page is published, it will present the original content prefaced by specific notifications.

If the editor/reader has contributed to the creation of this page has translation marking permissions:

Page Translation Settings

(For editors qualified to mark a page for translation)

If an editor, who at some point contributed to the page's creation, accesses the translation settings, they will be inquired about the content’s stability and readiness for community translation.

If content is not stable, no other options will appear in the translation settings, retaining the default "not set-up for translation" status (published only in original language).

If the content is stable and ready to go, the page for translation will be automatically and instantly configured (add <translate> and translation unit tags to content) and present expanded translation settings. The editor is able to scrutinize and adjust the auto-generated translation unit tags (further details will be provided later).

The majority of settings/interactions will remain constant. Editors will be asked about preferred translation languages, and languages to avoid. This change is designed to simplify by merging two tasks into one (setting up and marking for translation).

Once all is set and an editor marks for translation, the page becomes ready for community translation.

Page Translation Settings

(For editors NOT qualified to mark a page for translation)

If an editor, who at some point contributed to the page's creation, lacks the permission to mark a page for translation, they can still solicit someone to do so. This process diverges slightly from the aforementioned one. Such editors, when accessing translation settings, will be queried about the content’s stability and readiness for community translation.

If not stable (default status), no other options will appear in the translation settings, and the page will remain unprepared for translation (published only in original language).

If stable and ready, the page's editor can request another approving editor (with needed permissions) to mark the page for translation. The page's editor will adjust translation settings as they see fit, and also will have the option to leave additional instructions for the approving editor. The major distinction lies in that the final CTA is a request for marking the page for translation.

Marking For Translation

(Approving editor's perspective)
The preceding page will take last place on the current "page translation list" (subject to minor proposed changes). On this page, approving editors can view each page in line for translation marking and are given the liberty to select and mark them as per their discretion.

The approving editor, volunteered with marking this page for translation (on behalf of the page's editor), will also access the same page translation settings previously populated by the page's editor. They hold the discretion to alter any setting, although it is encouraged to adhere to the settings provided by the original editor to expedite the translation marking process.

In the scenario where a page editor chooses to leave a note for the approving editor, a banner will appear on the approving editor's end, both on the page itself (reader mode) and within the page's translation settings.

Next steps:

This project will leverage targeted user behavior research to obtain essential insights, specifically on the initial unaltered segment of the user journey: page creation. Our primary focus is on understanding the interaction of skilled users with translation-related markups.

Our proposed methodology entails conducting an observation study involving 4-6 proficient users within the forthcoming few weeks. The participants will be requested to initiate a new page (mock content will be provided by us), enabling us to gain critical points of data:

• Active User Interaction: Illustrating how proficient users incorporate translation markups into their work.
• Passive User Interaction: Demonstrating how proficient users address and correct markup errors (both human-induced and system-induced).

The acquired data will equip us to refine and solidify our design proposals and allow for the progression to the Minimum Viable Product (MVP) stage of this project.

The detailed user journey can be viewed in the corresponding Figma file at the following link:
Figma File

In T348519#9509333, @GLima-WMF wrote:

If the editor/reader has contributed to the creation of this page lacks translation marking permissions:

Starting the description of a call to action with You do not have the permission to is not very welcoming. What about This page can be marked for community translation / You can ask someone to mark it for translation in the page’s translation settings.?

If the editor/reader has not contributed to the creation of this page, they will not receive any notifications when reading this page.

Thanks for not displaying a banner to them! However, I think these users (especially translation administrators, but also users without rights) should also be able to prepare pages for translation, for example, with a link to the toolbox – not as distracting as the banner, but still reachable for those who are specifically looking for it.

If content is not stable, no other options will appear in the translation settings, retaining the default "not set-up for translation" status (published only in original language).

There is a third case, which is technically equivalent to this, but conceptually different: the page shouldn’t be made translatable either now or in the future – for example a discussion page (it will never become stable) or a page that contains no linguistic content (it merely transcludes other templates, it is a template itself that doesn’t contain burnt-in text etc.). I’d make it a third option (as its description shouldn’t contain the “just yet” phrase), but I’m also open to merging it with this not-yet-stable option.

If the content is stable and ready to go, the page for translation will be automatically and instantly configured (add <translate> and translation unit tags to content) and present expanded translation settings. The editor is able to scrutinize and adjust the auto-generated translation unit tags (further details will be provided later).

The majority of settings/interactions will remain constant. Editors will be asked about preferred translation languages, and languages to avoid. This change is designed to simplify by merging two tasks into one (setting up and marking for translation).

Generally looks nice, some points:

• The reason fields are inconsistent: there are reason fields for both ways to prevent translation, but there’s no reason field for setting priority languages. I think there should be a single reason field that applies all language settings (priority languages and preventing translation). I’d use a field set rather than a section to make it clear what the reason field refers to.
• MediaWiki forms have an option to display some form fields conditionally, based on other fields’ values. I think this should be utilized here: for example, the list of languages to prevent translation to should appear only if the user selected Prevent translations to specific languages.
• Currently there’s no option like Prevent translations to specific languages. What’s the use case for it?
• Could we see a proposed design on re-marking a page for translation? While on the first marking, all units have the same state (new), on re-marking, there are four states (unchanged, changed, new, deleted), and the list is currently a pain point (T52103, T298852, T300785), which could be improved a lot using this accordion design.

Hello @Tacsipacsi,

Thank you for your feedback, it was really constructive and I agree with everything. Let's go point by point:

Message text: I agree, I had not thought about starting with a negative. Will adjust it.
Banner/access to translation settings: Even if the banner is not visible, any user can still access the translation settings through the tools menu as you mentioned. We are still analyzing who can actually change a "random” page translation settings.
Translation options 3rd option: The original plan was to categorize those pages together with the first option (no, there's still changes being made). But if there's enough use case/need for it, we could definitely do 3 options. Will consult the team for feedback on this one, but I like it.
Reason fields inconsistency: I did not document here every single interaction possible in this form. I just showed one with everything visible for better understanding. But you are on point, the idea is to only show the extra fields when a certain option has been selected.
Reason fields for priority languages: We can definitely place a reason for prioritized languages too.
Language prevention options: Although it is not something specifically requested by the community, we want to give that option in case it is needed in the future.

Thank you for your feedback :)

Thanks for the replies!

In T348519#9513925, @GLima-WMF wrote:

Language prevention options: Although it is not something specifically requested by the community, we want to give that option in case it is needed in the future.

By “use case”, I don’t mean a specific request from the community, but a general idea about why we need it. I don’t have any idea why this would be useful; do you? If not, then it’s probably not needed.

Latest updates:
As I am moving to another internal project, here are the latest changes and documentations for this project.

Language selector: New proposal for the language selector layout/functionality to better reflect what is used today.

Figma file - https://www.figma.com/file/MkMIKQ3ti8BfFrlkdI2PzL/Translatable-Pages?type=design&node-id=171%3A225&mode=design&t=9nmOvmiAa8kEVn1p-1
Design Documentation - https://commons.wikimedia.org/wiki/File:Translatable_Pages_-_Design_Doc_April_2024.pdf