If you find pages with any of the problems discussed here, please amend the English page. If you are not able to do that, leave a message for the admin team.


Thread titleRepliesLast modified
Category Translations015:01, 8 January 2011
Cannot translate anything new112:27, 24 December 2010
Links in Category pages should be translated309:26, 6 December 2010
Breadcrumbs320:26, 28 October 2010
Wish about Translation plugin 118:35, 27 October 2010
Selecting a tab210:33, 3 October 2010
Language-selector under Toolbox in sidebar616:06, 2 October 2010
Corner-case markup114:33, 1 October 2010
Summary: Links to application pages019:52, 30 September 2010
Summary: Categories019:19, 30 September 2010
Summary: Page re-directs cause problems with links in translated pages018:55, 30 September 2010
Summary: Problem with links to subsections018:34, 30 September 2010
Summary: Using Smileys018:24, 30 September 2010
Quoting source code016:21, 30 September 2010
Summary of Marking for updates causes strange corruptions016:14, 30 September 2010
Summary of the Templates discussion016:03, 30 September 2010
Summary of Translating Pages - section sequence016:01, 30 September 2010
Summary of Images discussion015:53, 30 September 2010
Use of menuchoice tag1810:23, 30 September 2010
First Observations003:49, 7 July 2010
First page
First page
Next page
Next page
Last page
Last page

Category Translations

A recurring problem is that translators add the language code to the English category name, instead of using a completely localised name. We have some agreed names for most categories in most languages, linked from Translation_Help_Needed. If the category you need doesn't have a localised entry there, please add one.

When you add the new category name in place of the English one, you may get a red-link. Visiting the English equivalent page, you will see a one- or two-sentence description of what the category contains. Please add a similar description to your language category page. Thanks.

At some point we will need to clean up all the pages that have been wrongly categorised, to make them more useful to readers.

15:01, 8 January 2011

Cannot translate anything new

For the unknown reason, I cannot translate new messages from Ukrainian page. When I click on the translation links Opera and Firefox show the window with empty source field. I have tried to input the blind translation, but it only shows "Unknown error: ``tpt-unknown-page (unknownerror)".

Any hint will be much appreciated.

18:29, 23 December 2010

UserBase has moved to a new server, and in the process one link requiring change was overlooked. Sorry for the inconvenience, but you should have no further problem now.

12:27, 24 December 2010

Links in Category pages should be translated

Not sure if this is the right place to "complain" about this, but here is my problem: In the Category pages (for instance, shouldn't the link be translated ?

For instance the link Applications/Office/fr should be Applications/Bureautique (using the Page_display_title translation).

15:13, 3 December 2010

I'm not sure that that's possible at the moment. The best thing is to catch Nikerabbit on IRC and ask him about this. He's the author of Translate, and he may be prepared to put it on his to-do list :-)

10:20, 5 December 2010

I'm aware of it, but it's not an easy thing to solve.

10:23, 5 December 2010

I'm sure it isn't ;]

I just wanted to know if someone had knowledge of it.

Thanks :]

09:26, 6 December 2010


I noticed, that we now have breadcrumbs - great news! Unfortunately, they don't work well with translated pages. The page A/B/C will have a breadcrumb something like this [[A|A]] < [[A/B|B]] < C. The Danish version af the page is A/B/C/da, which will generate this breadcrumb: [[A|A]] < [[A/B|B]] < [[A/B/C|C]] < da which has two problems. First, the trailing da should not be there, nor the link to A/B/C (admittedly this is a minor complaint), and secondly, the links to A and A/B go to the English pages, where they should go to the translated pages A/da and A/B/da.

I can't see how this is implemented, but if it uses ordinary wiki syntax, I guess adding Special:myLanguage to all links would solve the second problem.

16:21, 27 October 2010

The breadcrumbs are actually built in to Mediawiki, and automatically generated. I will mention it to the Translate developers, to see whether they have any ideas, but there's nothing we can do in terms of mediawiki syntax.

18:24, 27 October 2010

I'm told that changes need to be made at code level. We have a "volunteer" that says he will try for it when he gets home in a few days. (For "volunteer" read "press-ganged volunteer" :-D )

18:33, 27 October 2010

That's great. If he needs a good illustration of the problem, a page like Amarok/QuickStartGuide/GettingStarted/da should do the trick. If feedback is wanted, I'd be happy to oblige.

20:26, 28 October 2010

Wish about Translation plugin

I add zh-tw zh-cn to assistant languages option, so when I open enhanced translation editor, the editor has two kinds of translation suggestions, the first one come from zh-tw page (Traditional Chinese) if the zh-tw page's translation is completed, the other come from Google Translation (Simplified Chinese).

I hope the suggestion which come from zh-tw page can be converted to Simplified Chinese via Google Translation service and vice versa. It will save my time in dealing with two kinds of Chinese.

zh-cn == Chinese(China) == Simplified Chinese, I hope the suggestions from zh-tw page is converted to Traditional Chinese

zh-tw == Chinese(Taiwan) == Traditional Chinese, I hope the suggestions from zh-cn page is converted to Simplified Chinese

Is it possible?

14:09, 13 October 2010

It is possible to do many things to solve this problem. I currently don't have time to implement them though. Some bright guy might be able to make a JavaScript gadget that does that.

18:35, 27 October 2010

Selecting a tab

When you describe an action that requires choosing a tab - is it correct to mark that as a menuchoice>

13:57, 2 October 2010

I think so. I feel that it is most logical to treat all named GUI element the same way. To most users buttons, icons, tabs and other elements that are directly visible are probably used more often than menu choices, so it seems they deserves to be highlighted as much as menu choices.

19:12, 2 October 2010

Yes, my instinct says that if it is a choice action it should be marked as a menuchoice. If anyone can think of a case where it causes a problem, this is the place to tell us :-)

10:33, 3 October 2010

Language-selector under Toolbox in sidebar

Please add Chinese(China) zh-cn and Chinese(Taiwan) zh-tw, thanks.

07:22, 1 October 2010

If you put zh-cn into the selector bar on the Translation Tool page you'll be taken to and similarly, putting zh-tw in, will take you to

I think it's just the unfamiliarity of the system. Let us know, though, if you can't find your way around.

For consistency, please make your category links in the form category-name/zh-cn- thanks.

19:10, 1 October 2010

They are different, I want to change userbase's interface language, look at this snapshot

The chinese category links have a lot of work need to do, I will modify chinese category link name when I have free time.

03:40, 2 October 2010

Ah - I thought you meant to the Translate language options. The interface settings are done from your Preferences screen, where zh-CN and zh-TW can be set. You can change them as often as you need to, it won't cause any problems.

If that still leaves you with things that need changing in the system messages I'll get someone with root access to join this thread.

06:20, 2 October 2010

Change Preference need an account and login in, but some visitors (guest) don't have (especially the person who visits this site first time).

another method is add this function to Translation Extension, for example, the extension not only redirect browser to /zh-cn page, but also change wiki' interface language(system messages) to zh-CN.

07:08, 2 October 2010

"Your wish is my command!" as the stories say. Pipesmoker has fixed it so that all languages are now available (if your browser is open from before the fix you will need to reload to see it).

13:17, 2 October 2010

haha, thanks

16:06, 2 October 2010

Corner-case markup

The how-to pages linked from Tasks and Tools set out the basic markup for most cases. However, there are a number of situations where the preferred markup is not clear. Before I can clarify those cases I need guidance from the translators. We can add examples to this thread until we are sufficiently clear to update the how-to pages. The first example I'd like you to consider is this section:

<example 1> Konqueror is primarily a web interface, but it can also function as a traditional file manager. If this is your preference, in System Settings, go to the Advanced tab and click on File Associations. In the list of Known Types, go to the inode/directory type. In the General tab at the right side of the window, select Konqueror in the Application Preference Order and click on the Up button until it is at the top. Click on Apply to save the changes. </example>

Please indicate how you would like this to be marked. If we can look at a few such cases we should be able to formulate useful guidance.

19:29, 30 September 2010

<example 1> Konqueror is primarily a web interface, but it can also function as a traditional file manager. If this is your preference, in System Settings, go to the Advanced tab and click on File Associations. In the list of Known Types, go to the inode/directory type. In the General tab at the right side of the window, select Konqueror in the Application Preference Order and click on the Up button until it is at the top. Click on Apply to save the changes. </example>

Actually I would recommend a few changes to the original text:

  • It is generally a bad idea to use names of GUI elements as anything other than names, så I would suggest replacing "In the list of Known Types,..." with "In the Known Types list ...".
  • I think inode -> directory is better than inode/directory; the latter is potentially confusing since it does not match one named GUI element.
  • I think "If this is your preference go to System Settings -> Advanced -> File Associations is a simpler and better way to present a sequence of GUI actions.
14:17, 1 October 2010

Summary: Links to application pages

<quote>I don't need to translate the application names, but what about those languages that have a non-latin alphabet?</quote>

After much experimentation it has been decided that markup that excludes elements from translation should be avoided whenever possible. That relies entirely on the experience of the translator to know what needs translation, but additional guidance can be written into [[EditMarkup|Prepare a page for translation]] where necessary.

With regard to links, it has been agreed that [[Special:myLanguage/Ark|<translate>Ark</translate>]] is the format that will be used for stand-alone links, such as the application-names in /Applications. To accommodate the different grammar needs, when the link occurs in a sentence the whole link should be left as within the translatable message.

18:42, 30 September 2010

Summary: Categories

There is a list of current categories and a set of pages where agreed translation of those categories can be found, linked from Translation_Help_Needed

As a general principle:

  • The UserBase page for the application should have its traditional category (manual writers can add the application category if they wish).
  • Tutorials, FAQ's etc should also have the traditional categories (again, the application category can be added).
  • Pages that are part of the manual should only have the application category.
  • The application category may also be used for any application that has many subpages.

New categories should only be considered if no existing one can be applied. If a new category is essential it must be added to all the translation tables listed on Translation_Help_Needed. Application-name categories may be omitted from those tables, as they will only be translated for non-latin alphabet languages. The translator is expected to know the official glyphs for the name translation.

19:19, 30 September 2010

Summary: Page re-directs cause problems with links in translated pages

KAddressBook and Plasma/FAQ are examples of pages where they are simply a re-direct to the latest version of the application. The problem arises if the text on one of those versioned pages contains something like [[KAddressBook/Enabling_Resources]]. There is no such section, because it's on the versioned page.

The solution is that the part that the reader sees can be trimmed for readability but the link must specify the version page.

18:55, 30 September 2010

Summary: Problem with links to subsections

Special:myLanguage finds the correct page, but then looks for a subsection with the English title, which of course it fails to find. Siebrand offers this workaround:

This will work if you add anchor points to your pages that cannot be translated. For example, add to the source text to allow anchors to always work. I experimented with this a while ago. The exact implementation may differ from what I write here, but I'm certain it's close. siebrand 08:44, 23 August 2010

This is working on a number of pages, so appears to be the correct solution for us.

18:34, 30 September 2010

Summary: Using Smileys

ASCII smilies cause problems for translators, because the system reports unbalanced parentheses. Instead, please us icons such as [[Image:face-smile.png]] Face-smile.png. Keeping the size below 15px constrains it vertically so that the text line isn't distorted.

Additionally, UserBase is linked to InstantCommons where you can search for other smilies or other images. You do not need any special addressing - they act as though they are uploaded onto our server.

18:24, 30 September 2010

Quoting source code

Templates are used for Input code and for Output code. In addition, syntax highlighting and the inclusion of line numbers is now possible. For details see

16:21, 30 September 2010

Summary of Marking for updates causes strange corruptions

There was a good deal of confusion caused when an English page was accidentally translated and had to be rolled back. When that was marked as ready for translation again, the language statistics appeared to be incorrect - and in fact the two sets of statistics did not agree. Nikerabbit explains this: <quote> Few notes that hopefully help to clarify things: Special:LanguageStats: if group is 100% translated, the default task is 'review all changes' (definition pink + translation green) instead of 'show untranslated' (untranslated blue, outdated pink). If this is confusing we should discuss how to make it less confusing.

If the one who marks page for translation chooses to not invalidate translations, those translation should never show up in the view of untranslated messages, nor affect translation percentages. The only difference is that if you somehow go and edit one of those, you will see a difference between the old and new definition like you see for other invalidated translations.

Nikerabbit11:16, 8 August 2010</end quote>

16:14, 30 September 2010

Summary of the Templates discussion

Some templates require localisation, others don't. We will for now include all templates in the translatable area, leaving the translators to make the decision. The difficulty, as I understand it, is that we have two types of templates - those with replaceable text, which should definitely be translated, and those with fixed text, where a localised version is substituted.

Any further ideas for clarifying this should be added to this thread.

16:03, 30 September 2010

Summary of Translating Pages - section sequence

If any new section is added between existing sections, the system will allocate a section number. The number is used by the system to know where it came from and where the translated section must be placed, but to the translator it will appear out of sequence.

It is essential that during the markup phase care is taken to ensure sufficient context remains for the translators to make good judgements. Translators meeting bad examples should alert the admin group.

16:01, 30 September 2010

Summary of Images discussion

Images need more white space around them than you might expect. A double-empty line above the image is desirable, a double-empty line below the image is required, to avoid the possibility of undesirable line-wrapping.

15:53, 30 September 2010

Use of menuchoice tag

Do we have a policy regarding use of the <menuchoice> ... </menuchoice> tag? The typographical guidelines mentiones only menu choices. Common practice also includes other named entities in the GUIs, such as buttons, textfields, dialogs etc. I assume this is all OK (IMHO it should be).

Recently I have come across a number of examples, where ordinary reference to things, that can be done in a GUI have also been enclosed in these tags, even though they do not specify a GUI element. An example might look something like this:


  • does useful stuff
  • change colour and flavour

I think this is potentially confusing and should be avoided. In cases like the above I don't think emphasizing is needed at all, but if some general terms must be emphasized, I think it is preferable to use ordinary bolding.

Should I remove superfluous menuchoice tags when I find them?

14:23, 22 September 2010

Yes. I talked to Yurchor about this, this afternoon, see User_talk:Yurchor#x.22Chatty.22_pages_-_hard_to_mark_up__414. Sorry for the extra work.

17:34, 22 September 2010

Yes. I talked to Yurchor about this, this afternoon, see User_talk:Yurchor#x.22Chatty.22_pages_-_hard_to_mark_up__414. Sorry for the extra work.

17:34, 22 September 2010

I came across a similar issue within link texts. Link texts already stand out, and adding extra emphasis to words in a link doesn't look good in my opinion. I haven't done anything about these - I know that there are other considerations, such as compliance with docbook, but does that apply to links?

09:12, 23 September 2010

I want to stick to compliance with docbook, and I'm honestly not sure of the answer to this. I suspect that the markup within the link may be unnecessary, but I'd like Yurchor to confirm this.

11:28, 23 September 2010

In fact, there is no such thing as compliance ;)

I have to re-write wiki2docbook to replace <menuchoice> with ''' and parse <keycap>Ctrl+F</keycap> to get <keycombo><keycap>Ctrl</keycap><keycap>F</keycap></keycombo>.

To understand things better, you can compare XML (exported from UserBase and slightly fixed) and DocBook from rekonq pages here, Amarok pages here, and KrossWordPuzzle pages here.

The only thing that is needed for successful conversion is the consistent markup in UserBase itself. Nothing more. There must not be markup like <keycap>OK</keycap>.

The stable rules (and of course, great look of pages) is the only thing that matter for documentation. Should we separate clearer what pages are and what pages are not documentation?

Surely, there is not much sense to prompt someone to use "this markup is a mess!"© just to write their plans on Telepathy, which are far from the real-world implementation. ;)

Thanks in advance

12:05, 23 September 2010

[quote]I have to re-write wiki2docbook to replace <menuchoice> with [/quote] - how useful is <menuchoice> then? It seems strange to me that I'm going through pages changing "" into <menuchoice> when you have to change them back.

I don't think there's much we can do to help with the keycap parsing, though. Sorry about the "OK" - I think I've only done it once, and it certainly wasn't intentional. I have a bad habit of thinking that I just need to get to a certain point before stopping work, when it would have been better if I had stopped a little earlier.

Maybe we need a thread somewhere more central about which pages need strict markup, and which are better served by just bold and italic carefully applied.

17:53, 23 September 2010

It is useful. It makes GUI elements on UserBase pages mauch more prominent.

For example, <menuchoice>Ok</menuchoice> gives Ok, but '''Ok''' gives just Ok which is not so visible. If you are trying to follow some instruction the former variant is much better, imho. ;)

I just want to say that DocBook compliance and UserBase markup have to be treated separately.

18:48, 23 September 2010

That was a very useful clarification. Looking at the docbook code for rekonq, I get the impression, that we should not use emphasis on application names when they appear in the text of a link. Is that correct?

05:26, 24 September 2010

Yes, it would be better, but emphasizing is not crucial. It can be easily tweaked during final polishing. Just a replace of <guilabel>rekonq</guilabel> with "&rekonq;".

The most ugly thing is to use bold typeface or <menuchoice> in section headers, or bold in {{Warning}}. Can it be added to Guidelines?


13:13, 24 September 2010

Yes, I'll do that. I guessed that it was better not to use it in section headers (I left some in because they were originally there, and I wasn't sure) but I wouldn't have thought of leaving it out of the templates - I assume that the same applies to Information, Notes and Tips templates.

15:12, 24 September 2010

Sorry to keep going on about this issue, but today I encountered some difficult problems translating KrossWordPuzzle. There are several problems all related to the use of the menuchoice tag.

First, It seems to me to be potentially confusing to ordinary readers to use the menuchoice tags for anything other than actually explaining how to do some task using the GUI. If we use menuchoice tags the way the are used in the feature list of KrossWordPuzzle, readers may confuse what is merely a list of capabilities with a discription of how to actually accomplish something (and be frustrated because the don't understand the "directions").

Secondly, using the name of a GUI element in its "literal sense", fx treating Open as a verb, is going to cause problems to many translators. The great differences between the various grammatical systems would force translators to write awkward (perhaps even ungrammatical) texts.

Thirdly, we can never be sure, that a translation of the GUI even exists. If it doesn't, a translator of the UserBase page may need to have English words in the translation. Here I am assuming, that the name of a GUI element should always appear in print exactly as it is shown on the screen, which seems highly desirably to me.

Therefore I would recommend that names of GUI elements are avoided in feature list and similar places where we are talking about the capabilities of an application, but not about how to accomplish anything in detail. Perhaps the simplest way to think about this is to allways treat the thing enclosed in a menuchoice tag as a proper name. Would it be a good idea to add something like this to the guidelines or are there better ways to deal with the problems?

16:09, 25 September 2010

I did say that you might find other pages that were written before I had had the conversation with Yurchor. The best thing to do is simply point me to them, and I'll fix the problems. I'm dealing with so many pages that I can't possibly remember which pages might be affected, so you will just have to prompt me. Sorry.

17:07, 25 September 2010

Actually, my latest complaint was about yet another kind of problem with the use of the menuchoice tags. The KrossWordPuzzle page did not "abuse" the tag in the way we talked about earlier, but I still think that the way menu items were referenced is unfortunate. I'm sorry I didn't make that clear enough.

06:38, 26 September 2010

Thirdly, we can never be sure, that a translation of the GUI even exists. If it doesn't, a translator of the UserBase page may need to have English words in the translation. Here I am assuming, that the name of a GUI element should always appear in print exactly as it is shown on the screen, which seems highly desirably to me.

I do not think it's a good idea to translate manuals for the applications with untranslated interface. Anyway, KrossWordPuzzle has not been translated to Danish yet. I cannot even to contact with the developer to ask him is it worth to put DocBook in the main SVN module, but that's the different story. ;)

To keep the good translations, I asked that screenshots can be translated, not as in Amarok Quickstart. It will be LP-quality translations of manuals if translators never use the applications. ;)

16:52, 25 September 2010

This author was active for a good while, but seems to have disappeared at the moment. I too tried to contact him. His apps are nice. I don't want to lose them.

I've re-marked the KrossWordPuzzle page. No guarantees that it's right, but of course you are free to edit as necessary.

The typographical guidelines are fairly straightforward to document. I'm beginning to think that we need a separate page for the actual markup for translations, and to ask translators to join the Talk page to help work out rules. I'm clear on straightforward decisions, but less formal pages are very difficult for me, and therefore I am not likely to write a good guideline for this.

I wasn't aware of the problem with the Amarok QSG pages - and there are a lot of them. I'll try to fix those over the next few days.

17:36, 25 September 2010

I agree that we should have a translation of the GUI before we begin translating the manual. I'm not so sure that the same always applies to traditional UserBase application pages, though.

06:51, 26 September 2010

Another question came up regarding the way we emphasize applications. The problem comes up in the genitive case: Where in English we would have fx "The Amarok menues ..." og "Amarok's menues ...", the proper Danish translation would be "Amaroks menuer ...", i.e. the same as the latter English form but without the apostrophe. Is it desirable to keep the s ending unbolded (it does look a little odd)?

16:46, 27 September 2010

Having had time to think about this, I think you are right. In future I will mark the whole word in bold. Please correct any instances you find meanwhile. Thanks.

10:23, 30 September 2010

First Observations

This is the summary of the conversation in June 2010:

Transferring the Danish translations of the first batch of pages to the new framework, I came across a few oddities:

  • In one page the ;) smiley was used inside a parenthesized remark.
Fixed - PageLayout guidelines warn against it and give image link instead.--annew 20:52, 28 June 2010 (CEST)
  • Sometimes a paragraph has an image or a snippet of code inserted with blank lines around the inserted item. In those cases the whole paragraph - blank lines and all - should be kept in one translation unit.
Off-line translation tools require headings to be in separate sections. Blank lines separate the sections, so this can't be fixed.
  • While I was translating the page on Kopete, the original was rearranged a bit. In particular, some sections were removed, and the remaining sections were renumbered. .... It should be OK to have translation units that are not consecutively numbered, right?
The sections should never be manually re-numbered. They will, sometimes, look non-consecutive, but the extension understands where they came from and where they must be put back. Manual editing breaks this.
  • The latest changes (which are not approved, which makes it so that the current translations are not outdated)
Correct - until the changes have been marked for translation they will not indicate the need for new translations. It may be that a number of changes are planned before the new version is complete.
  • Old pages have unacceptable typography.
Editing using Typographical_Guidelines will fix that.
  • Empty sections, prepared for information to be added later, are a problem when it comes to DocBook production.
They are fine in the early stages of building a page, but should be removed if they can't be filled before the page is marked for translation. --annew 12:28, 10 June 2010 (CEST)
  • There is a problem, that is bound to come up from time to time: Sometimes small changes are made to a page to correct spelling, grammar or formatting. Often, these changes do not affect the translations
When marking for translation it is now possible to check these as not affecting the translation.
  • If absolutely necessary you can use this to find all pages with fuzzy tags, then open section , delete fuzzy tags .--Qiii2006 19:36, 12 June 2010 (CEST)
  • Thanks, this is usefull! It doesn't solve the above problem, though, as the sections in question are not marked as fuzzy. I just checked - An_introduction_to_KDE/de doesn't appear on the German list, but the page is still marked as outdated (98% complete).
That was a different bug, now fixed.
  • By the way: Most (every?) time this problem has occured on one of the Danish pages, it has ben caused of two kinds of edits to the English original: Either a link of the form Page has been changed to Page or unneeded space characters have been removed for a wiki-link. I hope a solution can be found, for these kinds of changes are quite valuable to translators.

Another problem just occured to me. All links to translated pages needs to be changed as they are transferred to the new framework!

As we go through pages red-links are obvious, so we should be fine for fixing them. --annew 20:52, 28 June 2010 (CEST)
03:49, 7 July 2010
First page
First page
Next page
Next page
Last page
Last page

This page was last edited on 30 September 2010, at 18:57. Content is available under Creative Commons License SA 4.0 unless otherwise noted.