Change Details

Based on research (T334861), people were either not aware of Special:PagePreparation or found it not useful. This task is about discoverability, while functionality is tracked in {T348497}. Some specific issues to consider: - Visibility of the option to "Mark for translation" - Guidance to help understand the context (why mark for translation? what will happen next?) - Alternatives for those editors lacking the rights to mark the pages for translation. - Encouragement to make a page multilingual for the first time (we may apply this only when the next steps of the workflow have been improved too) Initial thoughts to start an exploration: * When would be the best time to let the user know they can make a page to be translatable? * The Vector omni language selector seems like a central point where to put an entry point * We can explore multiple different paths: ** redirecting user to Special:PagePreparation to do the preparation themselves *** after preparing, if they are admin we can point them to Special:PageTranslation to mark the page *** after preparing, if they are not an admin, we can explain that admins can mark the page for translation and the page shows up in a todo list for them (or do we need a different queue for manual requests?) ** letting the user to make a request that translation admin handles both preparation and marking for translation Scenarios to be considered will include (a) first time marking for translation, (b) marking for translation after the page has been updated. For those, users with and without the translation admin rights will be considered. = Observations = The study points out some pretty clear challenges we need to tackle. == High Entry Points == User research found that this feature, while very useful, is a bit too complex for our users, both new and regular. Right now, users can only activate it via the <translate> markup. This means they need to know how to edit source code, understand the <translate> markup, and how to use it. == Unclear Steps == Even when users manage to implement the translate markup, they still need to work through the process, which has some steps that can be a bit confusing due to similar wording but different outcomes. This process is in two parts: - Setting up Translation: This involves adding the <translate> tag and picking out the language/translation settings, such as choosing/preventing languages for translation, deciding if the title should be translated, etc. - Marking for Translation: This is where the page needs to be flagged for translation. If this doesn't happen, editors aren't notified and the page ends up in a queue waiting to be marked for translation. --- == Current User Flow == To add clarity, the current user flow was documented. Here's a summary of the process: Add user journey images **For a New Page:** 1. A new page is created by the editor. 2. Once the page is ready, 3. The <translate> markup is added in the source editing mode before the text and </translate> at the end. (Considered as 'setting up for translation’.) 4. Page is saved, also known as published. 5. On the page view, a button that says "mark this page for translation” appears above the content. 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. 7. "Translate this page” link appears on top of page in view mode 8. Translation by the community proceeds. **For Page Edits:** 1. An existing page is edited. 2. Once the update is ready, 3. Changes are saved, also known as published. 4. A button that says "mark this page for translation” reappears above the content on the page view. 5. User applies necessary translation settings, and if: 1. Permitted, the user marks the page update for translation. 2. Not permitted, the process ends here, the update is added to a queue for marking by others in the community. 6. "Translate this page” link appears on top of page in view mode 7. Translation of the update by the community proceeds. --- == Initial Thoughts == To overcome the challenges identified, several changes and proposals are suggested. 1. **Clarify the Process:** While the Wiki has thorough technical details, it could benefit from more user-friendly explanations. By improving the messaging throughout the user journey, emphasis can be placed on the significance of making a page translatable. 2. **Encourage User Adoption:** More visible ways for editors to access the feature can be introduced to lessen reliance on using the translate markup in the source editor. Additionally, more opportunities should be provided for editors to prepare a page for translation. 3. **Streamline the Process:** A quick amendment would be to use distinct terms for each stage of the process to avoid confusion. A more transformative approach could involve altering the process to reduce decision making on the user's part. More details to follow. == Explorations == Many suggestions have been considered, ranging from new entry points, altering user journeys, introducing new terminology, and adjusting settings. The details are elaborated in the link below. It's important to note that this is an ongoing endeavor and all technical specifics haven’t been finalized yet. However, the immediate focus is on the most promising revisions identified by the team. 1. **Highlight the Process Importance:** Upholding the foundation's mission of universal information accessibility rides heavily on this. Achieving a state where every page is readable in any language is crucial, making the translation of any given page (its preparation and translation) a primary target. (add banner screenshots) 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. (add entry points images) 3. **Default to Certain Translation Settings:** The process primarily demands two actions. First, making a page multilingual (a proposed new term for “set up for translation”), then flagging it for translation by the community. We could streamline this by defaulting all pages to be multilingual (yet easily reversible), leaving only the step of marking it for translation for the user. (add translation settings page image)

Based on research (T334861), people were either not aware of Special:PagePreparation or found it not useful. This task is about discoverability, while functionality is tracked in {T348497}. Some specific issues to consider: - Visibility of the option to "Mark for translation" - Guidance to help understand the context (why mark for translation? what will happen next?) - Alternatives for those editors lacking the rights to mark the pages for translation. - Encouragement to make a page multilingual for the first time (we may apply this only when the next steps of the workflow have been improved too) Initial thoughts to start an exploration: * When would be the best time to let the user know they can make a page to be translatable? * The Vector omni language selector seems like a central point where to put an entry point * We can explore multiple different paths: ** redirecting user to Special:PagePreparation to do the preparation themselves *** after preparing, if they are admin we can point them to Special:PageTranslation to mark the page *** after preparing, if they are not an admin, we can explain that admins can mark the page for translation and the page shows up in a todo list for them (or do we need a different queue for manual requests?) ** letting the user to make a request that translation admin handles both preparation and marking for translation Scenarios to be considered will include (a) first time marking for translation, (b) marking for translation after the page has been updated. For those, users with and without the translation admin rights will be considered. --- == Observations == The study points out some pretty clear challenges we need to tackle. === High Entry Points === User research found that this feature, while very useful, is a bit too complex for our users, both new and regular. Right now, users can only activate it via the <translate> markup. This means they need to know how to edit source code, understand the <translate> markup, and how to use it. === Unclear Steps === Even when users manage to implement the translate markup, they still need to work through the process, which has some steps that can be a bit confusing due to similar wording but different outcomes. This process is in two parts: - Setting up Translation: This involves adding the <translate> tag and picking out the language/translation settings, such as choosing/preventing languages for translation, deciding if the title should be translated, etc. - Marking for Translation: This is where the page needs to be flagged for translation. If this doesn't happen, editors aren't notified and the page ends up in a queue waiting to be marked for translation. --- === Current User Flow === To add clarity, the current user flow was documented. Here's a summary of the process: Add user journey images **For a New Page:** 1. A new page is created by the editor. 2. Once the page is ready, 3. The <translate> markup is added in the source editing mode before the text and </translate> at the end. (Considered as 'setting up for translation’.) 4. Page is saved, also known as published. 5. On the page view, a button that says "mark this page for translation” appears above the content. 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. 7. "Translate this page” link appears on top of page in view mode 8. Translation by the community proceeds. **For Page Edits:** 1. An existing page is edited. 2. Once the update is ready, 3. Changes are saved, also known as published. 4. A button that says "mark this page for translation” reappears above the content on the page view. 5. User applies necessary translation settings, and if: 1. Permitted, the user marks the page update for translation. 2. Not permitted, the process ends here, the update is added to a queue for marking by others in the community. 6. "Translate this page” link appears on top of page in view mode 7. Translation of the update by the community proceeds. --- === Initial Thoughts === To overcome the challenges identified, several changes and proposals are suggested. 1. **Clarify the Process:** While the Wiki has thorough technical details, it could benefit from more user-friendly explanations. By improving the messaging throughout the user journey, emphasis can be placed on the significance of making a page translatable. 2. **Encourage User Adoption:** More visible ways for editors to access the feature can be introduced to lessen reliance on using the translate markup in the source editor. Additionally, more opportunities should be provided for editors to prepare a page for translation. 3. **Streamline the Process:** A quick amendment would be to use distinct terms for each stage of the process to avoid confusion. A more transformative approach could involve altering the process to reduce decision making on the user's part. More details to follow. --- === Explorations === Many suggestions have been considered, ranging from new entry points, altering user journeys, introducing new terminology, and adjusting settings. The details are elaborated in the link below. It's important to note that this is an ongoing endeavor and all technical specifics haven’t been finalized yet. However, the immediate focus is on the most promising revisions identified by the team. 1. **Highlight the Process Importance:** Upholding the foundation's mission of universal information accessibility rides heavily on this. Achieving a state where every page is readable in any language is crucial, making the translation of any given page (its preparation and translation) a primary target. (add banner screenshots) 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. (add entry points images) 3. **Default to Certain Translation Settings:** The process primarily demands two actions. First, making a page multilingual (a proposed new term for “set up for translation”), then flagging it for translation by the community. We could streamline this by defaulting all pages to be multilingual (yet easily reversible), leaving only the step of marking it for translation for the user. (add translation settings page image)

Based on research (T334861), people were either not aware of Special:PagePreparation or found it not useful. This task is about discoverability, while functionality is tracked in {T348497}. Some specific issues to consider: - Visibility of the option to "Mark for translation" - Guidance to help understand the context (why mark for translation? what will happen next?) - Alternatives for those editors lacking the rights to mark the pages for translation. - Encouragement to make a page multilingual for the first time (we may apply this only when the next steps of the workflow have been improved too) Initial thoughts to start an exploration: * When would be the best time to let the user know they can make a page to be translatable? * The Vector omni language selector seems like a central point where to put an entry point * We can explore multiple different paths: ** redirecting user to Special:PagePreparation to do the preparation themselves *** after preparing, if they are admin we can point them to Special:PageTranslation to mark the page *** after preparing, if they are not an admin, we can explain that admins can mark the page for translation and the page shows up in a todo list for them (or do we need a different queue for manual requests?) ** letting the user to make a request that translation admin handles both preparation and marking for translation Scenarios to be considered will include (a) first time marking for translation, (b) marking for translation after the page has been updated. For those, users with and without the translation admin rights will be considered. --- == Observations === The study points out some pretty clear challenges we need to tackle. ===== High Entry Points ===== User research found that this feature, while very useful, is a bit too complex for our users, both new and regular. Right now, users can only activate it via the <translate> markup. This means they need to know how to edit source code, understand the <translate> markup, and how to use it. ===== Unclear Steps ===== Even when users manage to implement the translate markup, they still need to work through the process, which has some steps that can be a bit confusing due to similar wording but different outcomes. This process is in two parts: - Setting up Translation: This involves adding the <translate> tag and picking out the language/translation settings, such as choosing/preventing languages for translation, deciding if the title should be translated, etc. - Marking for Translation: This is where the page needs to be flagged for translation. If this doesn't happen, editors aren't notified and the page ends up in a queue waiting to be marked for translation. --- ===== Current User Flow ===== To add clarity, the current user flow was documented. Here's a summary of the process: Add user journey images **For a New Page:** 1. A new page is created by the editor. 2. Once the page is ready, 3. The <translate> markup is added in the source editing mode before the text and </translate> at the end. (Considered as 'setting up for translation’.) 4. Page is saved, also known as published. 5. On the page view, a button that says "mark this page for translation” appears above the content. 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. 7. "Translate this page” link appears on top of page in view mode 8. Translation by the community proceeds. **For Page Edits:** 1. An existing page is edited. 2. Once the update is ready, 3. Changes are saved, also known as published. 4. A button that says "mark this page for translation” reappears above the content on the page view. 5. User applies necessary translation settings, and if: 1. Permitted, the user marks the page update for translation. 2. Not permitted, the process ends here, the update is added to a queue for marking by others in the community. 6. "Translate this page” link appears on top of page in view mode 7. Translation of the update by the community proceeds. --- ===== Initial Thoughts ===== To overcome the challenges identified, several changes and proposals are suggested. 1. **Clarify the Process:** While the Wiki has thorough technical details, it could benefit from more user-friendly explanations. By improving the messaging throughout the user journey, emphasis can be placed on the significance of making a page translatable. 2. **Encourage User Adoption:** More visible ways for editors to access the feature can be introduced to lessen reliance on using the translate markup in the source editor. Additionally, more opportunities should be provided for editors to prepare a page for translation. 3. **Streamline the Process:** A quick amendment would be to use distinct terms for each stage of the process to avoid confusion. A more transformative approach could involve altering the process to reduce decision making on the user's part. More details to follow. --- === Explorations ===== Many suggestions have been considered, ranging from new entry points, altering user journeys, introducing new terminology, and adjusting settings. The details are elaborated in the link below. It's important to note that this is an ongoing endeavor and all technical specifics haven’t been finalized yet. However, the immediate focus is on the most promising revisions identified by the team. 1. **Highlight the Process Importance:** Upholding the foundation's mission of universal information accessibility rides heavily on this. Achieving a state where every page is readable in any language is crucial, making the translation of any given page (its preparation and translation) a primary target. (add banner screenshots) 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. (add entry points images) 3. **Default to Certain Translation Settings:** The process primarily demands two actions. First, making a page multilingual (a proposed new term for “set up for translation”), then flagging it for translation by the community. We could streamline this by defaulting all pages to be multilingual (yet easily reversible), leaving only the step of marking it for translation for the user. (add translation settings page image)