1,623
edits
Support/l10nPriorityPRD: Difference between revisions
Jump to navigation
Jump to search
→Requirements
(→Mockup) |
|||
| Line 42: | Line 42: | ||
=Requirements= | =Requirements= | ||
* The status of an article can be one of the following: | *The status of an article can be one of the following: | ||
** Not translated -- no translation of the article exists in the current locale | ** Not translated -- no translation of the article exists in the current locale | ||
** Translated -- the article is already translated | ** Translated -- the article is already translated | ||
** Needs review -- the translated article exists in the staging area only | ** Needs review -- a translation has been made, but it has not yet been approved (the translated article exists in the staging area only) | ||
* Ideally, this Localization Dashboard page would be a standard wiki page, but the generated parts of the page would be included somehow (e.g. using something like { | * Articles should be stored in a list (tracker db?), containing the following info: | ||
**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. | ** Article name/link | ||
**If we allow generated content be inserted using a syntax like { | ** Priority order | ||
***For example, if we wanted to provide a separate list of the articles waiting for review, we could use { | ** Score -- This is a way to define a more dynamic threshold than just "the top xx articles." In our case this would correspond to the page hits % the article has, so the score for the article in the example above would be 0.0245 (and our threshold would be 0.5). For other installations, the score might be based on something else, or might not be used at all. | ||
***Another example, if we wanted to list the | * Ideally, this Localization Dashboard page would be a standard wiki page, but the generated parts of the page would be included somehow (e.g. using something like {l10nProgressBar(list=kb, scoreLimit=0.5)}, where 0.5 means 50% which is our threshold. The progress bar would then show the progress to reach that limit (and anything >= 0.5 would be a fully green progress bar). | ||
**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 already working l10n fallback mechanism. So, these people would see the descriptions etc in English, but the generated data would be based on their native locale. | |||
**If we allow generated content be inserted using a syntax like {l10nTable(list, start, limit, scoreLimit, filter)}, that would give us a lot of flexibility in how we want to present the work. | |||
***For example, if we wanted to provide a separate list of the 10 first articles waiting for review, we could use {l10nTable(list=kb, start=1, limit=10, filter=needsReview)} | |||
***Another example, if we wanted to list the highest priority articles that need to be translated to reach our goal of 50% page hits, we would use: {l10nTable(list=kb, start=1, scoreLimit=0.5)} | |||
***If we wanted to list all Navigation articles (start pages, etc), we would use: {l10nTable(list=navigation)} | |||
*** This way, we have the flexibility to change the way we present the information. The system should also be flexible enough to work well for other localizable TikiWiki installations. This would even allow locale leaders to customize their view based on what works best for them. | *** This way, we have the flexibility to change the way we present the information. The system should also be flexible enough to work well for other localizable TikiWiki installations. This would even allow locale leaders to customize their view based on what works best for them. | ||
* 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. | * 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. | ||