View source for Talk:Translation Workflow

Note

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.

Hi, I have been using definition lists for listing off functionality in menus.

Definition lists, as you may know, kinda look like this:

Definition

Description

in wiki terms that's this:

;Definition :Description

And then mediawiki generates the html definition list, as officially described(http://www.w3schools.com/tags/tag_dl.asp):

<dl> <dt>definition</dt> <dd>description</dd> </dl>

Now, apparently, and this is not uncommon with html, people have abused ':' for indenting. Which is why I am supposed to remove them. Which in turn screws up the definition lists, and that makes for wonky html, which is sad.

If indenting is the problem, is there a way I can convince you to just remove the indent-styling from <dd> marked paragraphs? Or at the least give an official typography entry for handling definition lists?

Wolthera (talk)

I am not quite sure what you are referring to here: Off the top of my head I would think, that making description lists the way you describe is perfectly ok. Mind you, we do have a lot of detailed "rules" that have evolved over time, mostly to ensure that the the pages can be translated properly.

Could you provide a link to the page you are working on - it is often easier to comment on formatting problems in the actual context.

Claus chr (talk)

I use it all over the Krita manual, but here's a good example: https://userbase.kde.org/Krita/Manual/ColorManagement

This is the page that tells me not to use them: https://userbase.kde.org/Edit_Markup , it's the last bullit point of 'correcting old markup'.

Wolthera (talk)

I had completely forgotten about that particuar issue. I don't think this was ever meant to refer to definition lists - only to colons used on their own; or maybe it was solved with the neverland theme that we use now.

I had a look at your page. I looks fine in my browsers, so there is no reason not to continue using this markup. I'll try to find a better formulation on the Edit_Markup page to clarify (or maybe just remove the offending bullet). Thanks for pointing this out.

Claus chr (talk)

Great! I am glad I asked then :)

Wolthera (talk)

It would be great if somebody can turn the translation extension translation memory off. The current version makes the online translation absolutely impossible: it makes the server stuck and constantly shows error messages about timed-out operations.

PLEASE!!!!

Yurchor (talk)

I just encountered this problem in a single message. Now I can translate. :-)

Try again?

Abella (talk)

You shouldn't encounter it again. It is a Mediawiki bug, so we've disabled TM until the bug is fixed.

annew (talk)

On april 3 An_introduction_to_KDE was updated and fuzzybot stepped into action. However, instead of marking the affected section as fuzzy, it reverted the Danish translation to an ancient version (dating from before the translation system) and didn't mark the page as fuzzy - I only discovered the problem by accident. Fortunately all the links on the page were made invalid and lit up in bright red. The German page showes a similar problem; I haven't looked at the other translations, but it seems likely that they are also affected.

I hope this is an isolated insident, but we need to be on our guard until we know what going on.

Claus chr

Here we can see that was before many small sections is now one big section that retook the section identifier 8. Here you can see that it replaced those small sections with one big section 8 which at some point in the history contained the old translations of that whole big section.

Nikerabbit

In that case, I'm to blame - at least in part. Yecril97pl made changes to that page, then complained that links were broken because they were across sections (I can't remember the exact details). Since a bullet list doesn't need additional space, I removed the additional lines, but marked it as not affecting translations. The idea was that translators could pick it up when doing something more significant, but it would only be making work to do it separately. Sorry it caused a problem - I don't really understand what's happening with regard to the old translations. Perhaps if Nikerabbit can explain that, I can avoid it in future.

annew

If I understand this correctly, unit T8 is an old translation unit that has been removed long ago, so its contents is outdated. If so, we need to remove that unit-nr and reinstate the units from before Yecril97pl's changes, otherwise the recent translations with the proper links will be lost from translations. If Yecril97pl for some reason added unit-nr T8, that would explain why links suddenly failed.

At least it appears that fuzzybot has not gone mad after all, which is a great relief.

Claus chr

I never touched unit numbers. I only complained that the translation tags should not span sections.

Yecril71pl

Yes, I see that unit T8 was in the source all the time. It seems, however, that beeing placed between </ translate> and < translate> tags, it was "disabled". Following the various edits it must have somehow ended up beeing activated, causing ancient content to be inserted in the translated pages.

If this is correct then we should probably remove the T8 unit tag so that this kind of problem will not hit us again.

Claus chr

Can these meaningless changes be reverted? They do anything but harm and useless noise, imho.

This kind of formatting is inconsistent with the rest of the wiki and is very hard to be changed according to my language rules for this kind of texts.

Yurchor

I will attempt to track down all similar edits today and revert them.

annew

An introduction to KDE/uk still shows my layout. What is wrong with it?

Yecril71pl

Yes it is. After 5 or more tries to do this. It is hard to change this beautiful layout. Can you stop changing the layouts as you like? Thanks.

Yurchor

Yurchor, are you saying that we should avoid using ";" for formatting all together or are you simply saying don't change formatting unless it is actually broken? If the first is the case we need to add something about that on the Toolbox page. We do have a few pages, that use ";" formatting. Should we change those as we find them?

Claus chr

";" is good for anything but docs, imho. But I cannot understand when things that are not broken in any kind are changed just because someone likes something to be constantly changed. There are many not-so-popular pages (even without translations) to experiment with them.

Yurchor

The exact details are on the talk page.

Yecril71pl

I think we could open this page to translation since other similar pages are open to be translated. Idea?

Zhao Han

Please take a look at Digikam/Tutorials. After the re-organization the translated pages show at the beginning the old English messages followed by the new translated ones.

Caig

Was there an existing Italian translation? If not, it's Special:myLanguage doing its thing. This is a temporary situation, to help translators do a quick job of reorganising the page. Cut and paste from the old translation, instead of having to carefully translate. There is only Danish and Ukrainian to be done, after which the old stuff can be deleted from all the pages. I'd expect that to be done within the next few days. Hope that makes sense to you. The reorganisation is big, so we were trying to help cut down work.

annew

Hi, thanks for the answer. It affects all the translated pages. The reorganization is now completed as you can see here http://userbase.kde.org/index.php?title=Digikam%2FTutorials&action=historysubmit&diff=172679&oldid=170002

Caig

You have to do zero edit. Just add a space, then remove it, save the page, and everything will be right. ;)

Yurchor

It works! Very strange however. I keep it in mind for the next time. Thanks :)

Caig

My browser identification:

Opera/9.80 (X11; Linux i686; U; uk) Presto/2.8.131 Version/11.11

But when I open UserBase pages from anonymous user (with removed cookies) it shows me the pages in Belorussian (be). Can it be fixed?

Yurchor

I've asked Nikerabbit to look at this

annew

Check what you browser sends in it's Accept-Language headers.

Nikerabbit

Ah, yes, sorry for the panic. ;) Thanks for your advice.

Yurchor

And I thought I was being so clever, when we talked about making special:myLannguage links to non-existant pages red! I shoud have realized that this would not play well with translated pages. Links to untranslated pages now leads nowhere, rather than to the equivalent english page. Can we solve that while keeping the red link behaviour, when no english page exists? If not, it is probably best to revert to the old ways :-(

Claus chr

+1 This new behavior is just like remove Special:myLanguage at all.

Yurchor

Will get Nikerabbit to look at this

annew

Works for me. Please give examples and detailed steps so that I do not have to hunt for them.

Nikerabbit

The good news is I was wrong! I seem to have accidentally put in space characters around a backslash, so the link was wrong the whole time, I just never saw it before - because of the old Special:myLanguage behaviour the link used to show up blue. This actually confirms that the changed you made at the sprint was a really Good Thing(tm).

I do feel stupid, though, not to have investigated the problem a bit before complaining. Sorry about that.

Claus chr

Sometimes an author splits a bullet list with an empty line to make it more readable. This is disastrous for the translated pages. If you meet this, please correct the English page which will cause the re-marking for translation.

annew

I strongly agree. In fact, anything enclosed between some sort of brackets should be kept in one unit, i.e. without blank line in the middle. If for some reason such content must have blank lines, and so be divided in two units, please balance brackets in each unit by adding matching brackets in a comment, as fx

[[ <!--]]--> ...

with similar comments for other kinds of brackets. Unbalanced brackets (including ordinary parentheses) creates lots of problems for translators.

I was wondering, by the way, if a

<br />

could replace a completely blank line in case it really is needed?

Claus chr

I have added a section to your Build page. Please let me know whether it works.

annew

It works! the lines before and after the <br /> appear in the same translation unit.

Claus chr

I have added a section to Typographical_Guidelines. Please check that the instruction is clear and amend if necessary.

annew

I think it is very clear. I added two sections on keeping units together and on balancing brackets. Do they belong there?

Claus chr

Might they be better in Edit Markup? While we want to avoid duplicating sections (maintenance, etc.), a link between Typographical_Guidelines and EditMarkup would be sensible. Can I leave you to deal with this? Thanks

annew

I'm sorry, but Edit Markup is protected, so I can't edit it.

Claus chr

Oops - I forgot that we marked the Help pages as protected. I've done the edit. Sorry.

annew

When translating the page Kdevelop4/Manual/What is KDevelop? I encountered a problem with the name of the .po file: Downloading the page gave me a file whoes name had been truncated at the question mark, i.e. the downloaded file was named "page|KDevelop4/Manual/What is KDevelop" with "?_da.po" having been thrown away. Now, this is easily remedied; however, uploading the file after translation turned out to be difficult. When I tried to upload it to Special:ImportTranslations the name was again truncated, and this time I couldn't just add the missing postfix - the relevant field is not editable.

It seems, that this is a Firefox problem. At least I managed to upload the .po file without problems using Konqueror. However, with many distros using Firefox as their standard browser, this may cause problems.

Is it possible to remove punctuation signs from the names of .po files or must they match the page name exactly? And if they must, should we avoid punctuation in page names?

Claus chr

I think this may have to wait until the sprint, when we can discuss it with Nikerabbit.

annew

There is no hurry. I know only of this one example. Do you know if many translators download the po-files? If so, it might be a good idea for me to temporarily add a warning to the English page. Ideally it would of course be better to have such text in the Talk page, but I don't think it will be much help there - most likely, translators won't think to consult the Talk page for such information.

Claus chr

Nikerabbit says that the question mark shouldn't be a problem, so we will need to look at that, at the sprint.

annew

Recently the {{KDE3}} template was modified to include code, that automatically adds [[Category:KDE3]] to the page. This has two consequences that may have been unintentional:

First, the {{KDE3}} template is used on some pages that was not previously in the KDE3 category, for example to mark a section that refers specifically to KDE3 in a page about a KDE 4 application.

The other thing is that previously each language had its own version of the KDE3 category (KDE3/da, KDE3/de and so on). With the new system all the translated pages will end up in the same KDE3 category.

Claus chr

The first doesn't worry me at all. If there is KDE 3 content on a page, it should be in that category, to draw my attention to the fact that it will eventually need editing out. That's the whole purpose of the category - to enable us to find material that needs deleting or editing, when the time is appropriate.

Actually, I'm not sure that the second one matters either, as the KDE3 category is a hidden category, intended for administrative use only. It probably doesn't help to have localised versions of that. When the English page gets edited the translators will automatically get the changes in the normal way.

annew

Perhaps we should start removing [[Category:KDE3]] markup as we come across them. (We would first need to make sure, that those pages have the {{KDE3}} somewhere). Or do those explicit category markups still serve a purpose?

Claus chr

The template was intended from the start to put those pages into the category, but it didn't work. Now it does work we should remove the manual ones as we come across them, but they do no harm if they are around for a while. They don't cause the page to appear twice, for instance.

annew

It is suggested that versions of pages such as the Plasma/FAQ earlier than KDE 4.4 are probably not worth translating - since few people will still be using them. Thoughts?

annew

Agreed.

Yurchor

It makes good sense. However, in that case I think we should remove links to them and either remove them completely or only link to them through a page of old and unmaintained pages.

Claus chr

We are experimenting with the possibility of using an Archive namespace, but ran into a problem. Hopefully this will be possible soon. If it's not fixed before then we should tackle it at the WebWorld2011 sprint.

annew

Page redirection does not work with the translation system! See for example the first two links in Plasma#Further information: Plasma/FAQ redirects to Plasma/FAQ/4.4. However, for the Special:myLanguage 'trick' to work we would need a Plasma/FAQ/da redirect to Plasma/FAQ/4.4/da and so on for each translation. (I assume this would work.)

This kind of solution does not seem to be maintainable. I don't see any solution to this problem that is both maintainable and elegant, so I propose a simple, maintainable but not very elegant solution:

Create an actual Plasma/FAQ page containing only links to the various versions of the FAQ. That way, when a new version of the FAQ is created, we just add a link to it here. Of course this link page should be translated. (Perhaps it would be easier to create a new Plasma/FAQ/Index page and change all links to Plasma/FAQ to this page?)

Claus chr

Do you have time to do a similar job on KAddressBook please?

annew

Claus chr

The deed is done. I created KAddressBook/index with the links.

I have also changed alle the links to KAddressBook that I could find to this page. That was a bit hit and miss, though. Special:WhatLinksHere gave no usefull information and the search box just took me to the page KAddressBook_4.4, so I manually went through the pages I could think of (Applications/Office as well as KOrganizer and its subpages and links found in these). It is likely that I didn't find all links.

In the process of doing this I came across a problem in the page Akonadi 4.4/Troubleshooting. It contained many multiline input and output displays that didn't show properly: only the first line of the display was put in the box, the rest appeared below as ordinary lines. The problem was caused by preceeding the templates with one or more colons for indentation. I removed the colons, so the page displays properly now.

Claus chr

Thanks. I've seen the work and marked it as ready for translation. The problem with the multiple colons is known. Apparently when the system has to translate the wiki markup into html for display it hits this problem. Our solution is to add some indent to the style for bullets, and where more is needed a single colon can be added. Any instances of more than one colon should be cut down to a single one if really necessary, just as you have done, whenever we come across them.

Thanks for the work

annew

The problem I was talking about is related but distinct. It concerns the Input and Output templates. With those there can't even be a single colon, since then lines other than the first end up outside of the box. If you write

{{Input|1=1. line
2. line}}

you get

1. line
2. line

but precede it with a single colon like this

:{{Input|1=1. line
2. line}}

and you get

1. line

2. line

Claus chr

It seems that some authors prefer to format the pages as they like, using some entities (like &emsp;, &mdash;, etc.). If the usage of such entities is necessary for the wiki, can it be regulated by the translation or author rules?

Thanks in advance.

BTW in Opera (Linux) &emsp; looks like empty bar (with the border). 

Yurchor

I'm not sure what we can do about this. We make typographical guidelines, but I don't see any way that we can enforce them. I'll contact this particular author and see if I can persuade him/her to change the entries. I suspect that the pages in question are being prepared in some html writer and pasted in, but again, I can't actually stop that. All suggestions for dealing with this sort of problem would be gratefully received.

annew

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.

annew

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.

Yurchor

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.

annew

Not sure if this is the right place to "complain" about this, but here is my problem: In the Category pages (for instance http://userbase.kde.org/Category:Applications/fr), shouldn't the link be translated ?

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

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 :-)

annew

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

Nikerabbit

I'm sure it isn't ;]

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

Thanks :]

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.

Claus chr

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.

annew

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 )

annew

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.

Claus chr

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?

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.

Nikerabbit

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

annew

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.

Claus chr

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 :-)

annew

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

If you put zh-cn into the selector bar on the Translation Tool page you'll be taken to http://userbase.kde.org/index.php?title=Special:LanguageStats&code=zh-cn and similarly, putting zh-tw in, will take you to http://userbase.kde.org/index.php?title=Special:LanguageStats&code=zh-tw

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.

annew

They are different, I want to change userbase's interface language, look at this snapshot http://is.gd/fFIAm.

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

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.

annew

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.

"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).

annew

haha, thanks