Closed Bug 414361 Opened 13 years ago Closed 13 years ago
Make auto-generated content localizable
Some auto-generated items in articles are always displayed in en-US, such as "Table Of Contents" and "Show content customized for:". Also, sidebar items are not localized either. We need to make it possible to localize _all_ elements.
The ideal situation would be to let a certain group of "trusted" localizers to localize those elements. Those are template elements
The ideal situation would be to let a certain group of "trusted" localizers to localize those elements. We need to decide if I should make it possible for such localization to be done through the web interface, or if it has to go through SVN. This is a convenience vs. security question (morgamic, comments?). Template element localization is not like content localization as there is no wiki history to revert stuff in the event of things going wrong. Also, it is a all-or-nothing thing, i.e. someone given ability to customize these elements can do it for the *entire* site.
The other questions I have are: 1) What is the degree of tolerance for "partially translated elements" in the transition? This will affect the mode of committing (SVN vs directly?). 2) Is there a requirement for someone to view English elements when reading a French-language page, for e.g? 3) What should take precedence when determining the lang of these elements? suggestion: (1) browser settings, if internal user pref setting not set, (2) internal user pref setting, if set, (3) english otherwise.
(In reply to comment #3) > The other questions I have are: > > 1) What is the degree of tolerance for "partially translated elements" in the > transition? This will affect the mode of committing (SVN vs directly?). I think we could tolerate partially translated elements in general. However, there seem to be elements that aren't even localizable, like the user module mozilla_morehelp. If we choose to go the SVN route, maybe it would be easiest to just send out that config file you linked to (e.g. http://svn.mozilla.org/projects/sumo/trunk/lang/fr/language.php) and ask localizers to translate them, and then we would merge them back into SVN again. As long as the file includes all strings we want to localize, that is. > 2) Is there a requirement for someone to view English elements when reading a > French-language page, for e.g? This should probably be a fallback mechanism based on your language preferences (either detected, or specifically set). In other words, if your primary language is French, and you're viewing a page only available in en-US, you probably still want to show e.g. the sidebar items, the "Table Of Contents" string in French. Similar to wiki.mozilla.org; when your language preferences is set to Swedish, you see "Innehåll" instead of "Table Of Content", even though the actual article is English only. > 3) What should take precedence when determining the lang of these elements? > suggestion: (1) browser settings, if internal user pref setting not set, (2) > internal user pref setting, if set, (3) english otherwise. I agree with that priority.
this is basically working, with some "caching" issues to be worked out, and some limitations to be improved
I am marking this bug as fixed. There are two modes to translate these elements: 1) an interactive translation mode where clicking on the "ring" next to the string opens a popup that allows for translating it. 2) a more old-fashioned "table" mode where you can search for strings containing a search term, and then translate the string from a table. This can be used for strings that are not accessible from the UI when logged in, for example. The two main limitations outstanding now have their own bugs: bug 419785 and bug 419788
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.