Support/l10nPriorityPRD: Difference between revisions
< Support
Jump to navigation
Jump to search
No edit summary |
|||
| Line 23: | Line 23: | ||
* Actionable links, making contributing straightforward | * Actionable links, making contributing straightforward | ||
=Requirements= | =Requirements= | ||
* Ideally, this Localization Dashboard page would be a standard wiki page, but obviously the generated parts of the page would be included somehow (e.g. using a content block like {content label=mostPopularSupportArticlesSummary} for the progress bar and summary of the "Most Popular Support Articles" section). This would allow other locales to easily translate the dashboard while not messing up with the generated content. And obviously, for locales that are fine with using this dashboard in English, that would just work automatically using our l10n fallback mechanism. So, these people would see the descriptions etc in English, but the generated data would be based on their native locale. | |||
* Because the [http://support.mozilla.com/en-US/kb/Weekly+common+issues Weekly Common Issues] list is calculated using a combination of TikiWiki data and web analytics software (in our case Omniture), we need the ability for an external system to "tell" TikiWiki the priority of the KB. Marc Laporte mentioned a tracker db; seems like a fine solution to me. So, a tracker would contain a list of articles in a specific order. | |||
*We need to be able to put data in this tracker using e.g. a bash script or similar. | |||
**Alternatively, we need a way for TikiWiki to import data from e.g. a CSV file to a tracker. | |||
* In our case we would need three separate priority lists, so three trackers: | |||
** One tracker for the support articles -- what we call the Knowledge Base (KB). This is the tracker that we would need to allow an external system (bash script or similar) to write to. | |||
** One tracker for the "navigation pages" (start pages, and other pages that are essential to the navigation) | |||
** One tracker for the "contributor documentation" -- pages that aren't meant to be used for end-users, but for contributors | |||
* A function that can take one of these trackers as a parameter, the locale as another parameter, and return a formatted table (as shown in the mockup above) with the status of these articles. | |||
* Another function with the same signature that returns the next untranslated article. If all articles are translated, nothing would be returned. If only a staging copy exists (the "Needs review" state), that article counts as untranslated, so it should be returned. | |||
* Another function with the same signature that returns a summary (total number of articles, and number of translated articles). | |||
* A function that can draw a progress bar based on the summary in the function above. | |||
* The status of an article can be one of the following: | |||
** Not translated -- no translation of the article exists in the current locale | |||
** Translated -- the article is already translated | |||
** Needs review -- the translated article exists in the staging area only | |||
Revision as of 16:28, 16 February 2009
Overview
Localizers of SUMO lack a clear overview of the localization work that is needed and what is most important. We're currently doing a good job of explaining how to translate articles, but not which articles are most important. The purpose of the l10n priority milestone is:
- To provide a clear overview of the l10n work on SUMO
- To answer the question: "which article is the most important to translate?"
- To define a baseline of what we define as a healthy status of a locale
Mockup
The page consists of three main areas:
- Localization Priority -- A high-level overview of the l10n work that defines the baseline of what we call a healthy l10n status. Locales that complete the items in this list are considered to be performing well
- What's the most important article to translate next? -- A simple actionable item that makes it easy for a localizer to see what translation work has the highest impact in terms of the number of users that benefit from the work
- Article lists -- The actual lists of prioritized articles that need translation. Initially, we will maintain and present at least two lists: navigation pages, and top support articles
Progress bars
- Header clickable link to anchor further down the page with the actual list
- Progress bar dynamically generated based on the status of a l10n priority list
Article lists
- Dynamically generated and insertable into a standard wiki page
- Status visually emphasized using colors
- Actionable links, making contributing straightforward
Requirements
- Ideally, this Localization Dashboard page would be a standard wiki page, but obviously the generated parts of the page would be included somehow (e.g. using a content block like {content label=mostPopularSupportArticlesSummary} for the progress bar and summary of the "Most Popular Support Articles" section). This would allow other locales to easily translate the dashboard while not messing up with the generated content. And obviously, for locales that are fine with using this dashboard in English, that would just work automatically using our l10n fallback mechanism. So, these people would see the descriptions etc in English, but the generated data would be based on their native locale.
- Because the Weekly Common Issues list is calculated using a combination of TikiWiki data and web analytics software (in our case Omniture), we need the ability for an external system to "tell" TikiWiki the priority of the KB. Marc Laporte mentioned a tracker db; seems like a fine solution to me. So, a tracker would contain a list of articles in a specific order.
- We need to be able to put data in this tracker using e.g. a bash script or similar.
- Alternatively, we need a way for TikiWiki to import data from e.g. a CSV file to a tracker.
- In our case we would need three separate priority lists, so three trackers:
- One tracker for the support articles -- what we call the Knowledge Base (KB). This is the tracker that we would need to allow an external system (bash script or similar) to write to.
- One tracker for the "navigation pages" (start pages, and other pages that are essential to the navigation)
- One tracker for the "contributor documentation" -- pages that aren't meant to be used for end-users, but for contributors
- A function that can take one of these trackers as a parameter, the locale as another parameter, and return a formatted table (as shown in the mockup above) with the status of these articles.
- Another function with the same signature that returns the next untranslated article. If all articles are translated, nothing would be returned. If only a staging copy exists (the "Needs review" state), that article counts as untranslated, so it should be returned.
- Another function with the same signature that returns a summary (total number of articles, and number of translated articles).
- A function that can draw a progress bar based on the summary in the function above.
- The status of an article can be one of the following:
- Not translated -- no translation of the article exists in the current locale
- Translated -- the article is already translated
- Needs review -- the translated article exists in the staging area only


