Talk:Translation Workflow

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. This resulted in the translation of that section to be marked as "out of date". Apparently the translation system keeps an eye on unbalanced parentheses. This is confusing for readers and translators alike, so I suggest that we encurage authors to avoid using smileys or anything else, that results in unbalanced paranteses.
  • 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. The reason is, that in translating a paragraph, one does not allways translate sentence by sentence. Sometimes it is nessary to move things around a bit in order to make the text flow naturally.
  • 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. This had the unfortunate effect that some of the translated sections no longer matched the original ones. Even worse, the sections were marked as if they were current, so it is a bit a lucky stroke that I even noticed the problem. It seems, that we should not renumber sections after removing something or after inserting new sections. It should be OK to have translation units that are not consecutively numbered, right?
In order to understand what happened consider this example:
Let's say, that a page originally contains 10 translation units numbered 1 to 10. After I start translating the page, someone else modifies the original page as follows: some sections are removes - lets say units nr. 4 and 8. As I finish translating the (original) page and view the result, what I see are are translated units nr. 1 to 8 - in other words, the two sections removed from the original still appears in the translation while the last two sections are missing from the translation. --Claus chr 18:03, 9 June 2010 (CEST)
2nd issue: Is it possible to just make them one section by removing the empty lines between?
3rd issue: Old numbers are not reused for new sections, unless someone changes the section markers by hand. The latest changes (which are not approved, which makes it so that the current translations are not outdated) seems to do something like that. I'd expect these kinds of problems go away once we figure out the best practices and changes pages less often. – Nikerabbit 20:28, 9 June 2010 (CEST)

Another issue for the 'best practices' - the offline tools have problems with combined bold and italic, so that should also be discouraged. IMO the problem will be easily fixed when we get the new theme that makes links easier to see without using bold. --annew 21:54, 9 June 2010 (CEST)

Empty sections, prepared for information to be added later, are also 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, but even so the corresponding section in the translated page will be marked as beeing out of date. Fx after I translated the page An Introduction to KDE it had a small edit, that was soon reverted to the original again. As a consequence, the Danish page is now marked out of date (no actual section is colored pink, though). I have tried to change the offending section, save the change and then change it back again but with no effect. This is unfortunate, as it will likely reduce readers confidence in the translations when they are marked as incompletely translated. Can we get rid of these markings? --Claus chr 16:01, 10 June 2010 (CEST)

I found a (the?) solution to this problem. The offending section is marked with a FUZZY tag - removing this from the translated section marks it as being up to date. Unfortunately, the FUZZY tag does not appear until the section is opened for editing, so when the section is not colored pink it may involve a bit of poking around to find it. --Claus chr 17:45, 10 June 2010 (CEST)
Well, not the solution, it appears. Sometimes the offending section is not marked as FUZZY. Instead, when you open the section for editing, you may see a pair of 'Previous content'/'New content' columns on a yellow background. Even if the translation doesn't need any updating, it seems that you need to make some change and then save it to get rid of the 'out of date' marking at the top of the page. --Claus chr 18:09, 10 June 2010 (CEST)
If that turns out to be the only reasonable solution, we'll have to write into the guidelines that an extra space added is probably sufficient to achieve it. Not ideal, but a workaround until a better solution is found. --annew 21:55, 10 June 2010 (CEST)
No need to change anything, just saving th message as-is will clear the status. If outdated sections are not marked with pink/fuzzy tag, it's a bug. I need clear steps to reproduce to investigate. Not being able to update page without marking translations outdated is a missing feature.
The same problem appears on this page: An_introduction_to_KDE/de (and probably on several others). When I enter the translation page, no section is marked as FUZZY, and no section appears on a pink background. I did at one point try to just save the offending section of a similar page, but that didn't help. (Maybe I should have given the database a little time to update before I checked the page?)--Claus chr 17:15, 11 June 2010 (CEST)
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).
I find this problem in An_introduction_to_KDE/zh-cn and zh-tw too. I saved zh-cn page twice to make it 100% complete (1,2), another zh-tw is still 98% complete. Save section directly without modify message is useless. This problem appears because fuzzybot marked page as outdated, but didn't mark any section with fuzzy tag --Qiii2006 11:58, 13 June 2010 (CEST)
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|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! I think it is probably best to wait until a fair amount of pages have been transferred; otherwise we would have to constantly go over alle our pages to correct links to newly transferred pages. Could this problem be solved by a bot? If so, it would take a heavy load off our shoulders. --Claus chr 19:43, 10 June 2010 (CEST)

Yes, we are going to need a small army of helpers for this if we can't find any way of automating the checks. We are aware of it, but haven't yet put in place any plan for dealing with it. I've been rather taken aback by the speed of uptake, and it's now time to make sure that we include all the issues into the guidelines. We'll be working on that over the next few days. --annew 21:55, 10 June 2010 (CEST)

(Fixed) Translation sections in categories

I noticed translated categories pages list also translation sections containing category statements. For example (and to explain better :D) look this. I think readers can be confused a bit.--Caig 11:51, 13 June 2010 (CEST)

I see this too. I wonder if it is possible for the wiki to not list anything in the Translations namespace in normal categories. --Nilli 13:45, 13 June 2010 (CEST)
This is on the To-Do list - see . As usual, the bottleneck is man-power. --annew 13:31, 14 June 2010 (CEST)
Update - this is fixed, but needs manual intervention for the pages already (wrongly) listed. Please open the page and re-save it. The problem should disappear. Isn't it wonderful to have such rapid response from the developer :-) --annew 14:23, 14 June 2010 (CEST)
Really wonderful! --Caig 15:18, 14 June 2010 (CEST)
Seems no manual intervention is needed anymore, as nobody has touched "my" pages but they don't show up in the categories. Pass a big thank you on to the developers! --Nilli 21:50, 14 June 2010 (CEST)
Yep, I found a maintenance script that fixed them. – Nikerabbit 21:53, 14 June 2010 (CEST)


To avoid the ugly shortened line immediately after an image both writers and translators needs to take action. I have found this to work: In the original English page, we still need two blank lines following an image to avoid the problem. If the image is in a translation unit of its own, translators need to terminate their input with a newline character. --Claus chr 10:18, 16 June 2010 (CEST)

Preparing pages for translation

I see that already some pages are marked with This page contains changes which are not marked for translation. Is there a process in place to prepare the pages to allow the translators to work on the added / changed text? The same question is also true for pages that are not currently prepared at all for translation. --Sordon 13:51, 17 June 2010 (CEST)

The first issue is that too many pages were prepared for translation at once. More important even than that is that we had no documented guidelines for typographical issues, which caused a number of problems for the translators. This week we have worked on writing such guidelines (and some new features will be added in a day or two) and fixing other issues. The result is that we have had no time to prepare other pages.
In fact I will not be preparing new pages for a while yet. The first task is to go through those Group 1 and Group 2 pages that we selected as priority, and check them against Typographical_Guidelines. As each page is checked then it will be re-marked, and that will be the final version, subject only to genuine updates. If you have time to spare, please help check those pages, and either ping me on irc or email me to tell me when pages are finished. Thanks. --annew 14:34, 17 June 2010 (CEST)
Hello Anne, ok fair enough. So I will take a closer look on these pages. One question, though. The page Quick Start is mentioned as an important page. But I can't find any other pages pointing to this page. Am I missing something? (Nevertheless the page is now translated to German) --Sordon 15:06, 17 June 2010 (CEST)
No, you're not. The intention is that the current Help link will be changed to point to that page. The front page is also to be re-written to give a clearer indication that there are help pages for getting settled into UserBase - the Getting_Started category - and for contributing. Maybe we will add a site notice (which displays on every page) pointing to Quick_Start as well. If you are interested in discussing such things, you might like to drop in to #kde-www on Saturday mornings, the time we have allocated for discussing web site issues. --annew 08:58, 18 June 2010 (CEST)
Thanks for the detailed answer. Now it's all clear --Sordon 10:32, 18 June 2010 (CEST)

Translating pages

Translating a page from scratch I have come across a problem. When a page is worked on after beeing marked for translation, it is quite likely that a new section will be added between original sections, and the number of its translation units is going to be out of sequence. This means that the translation page will show units in a mixed-up sequence. For long pages in particular this can be a problem for translators, since it is often impossible to find the right translation of something, when you don't know the context. Parley/Manual is a good example of this problem.

Is it possible to make the translation system serve translation units in logical rather than in numerical order? --Claus chr 09:27, 20 June 2010 (CEST)

I thought it already did. I will add it to the issue list at – Nikerabbit 15:32, 20 June 2010 (CEST)

Please keep logical section together in one translation unit!

Sometimes a section has displayed material in the middle, like a line of code to enter in a console - sometimes this even appears in the middle of a section. It is not a good idea to split such sections in several translation units. Working with such broken sections means, that we must try to translate them out of context which is difficult and error prone. (Of course we could have the original page open in a separate tab, but having to search the page for the part corresponding to a particular unit doesn't exactly make the job of translators easier.)

For a particularly striking example of the ill effects of "overly agressive" splitting of the text please refer to Akonadi 4.4/Troubleshooting. I the English original, translation units nrs. 74, 106 and 107 make up one sentence - unit 106 is a command displayed in the middle of the sentence. In the Danish translation the whole section precedes the command, so the translation of unit 107 should be empty - I don't know how this can be accomplished, so at present the Danish page shows the English end of the section after the command.

This particular problem can certainly be solved by making a less naturally flowing translation or by rephrasing the English original to something less fragmented. The real point, however, is that this kind of problem is going to keep popping up in the most unexpected places unless we keep full section together in single units. I am sure that this problem is going to be even worse for languages less closely related to English. --Claus chr 21:35, 24 June 2010 (CEST)

I have discussed this with yurchor, who also knows the needs of the docbook translators. He agrees that removing the white space around the single lines of code would be a sensible resolution to this. OTOH, he also raises the question as to whether we should treat single lines of code in the same was a blocks of code, i.e. box them, for consistency. What is your opinion on that? This seems the ideal time to iron out rules :-) --annew 14:41, 26 June 2010 (CEST)
I also think that it is a good idea to treat single lines of code the same as blocks of code.
OK - I'll get that written into the guidelines, and make changes when I do edits.
I agree that now is a good time to think through the typographical guidelines. I have noted that some pages have an excessive amount of emphasized text. I think this may render the text less readable, so maybe we should consider removing some items from the list of things that should be bolded. I would suggest that application names don't neeed to be bolded. They nearly allways contain capital letters, and that should be enough. We would then have to be consistent with capitalization af application names, but that is probably a good thing anyway. --Claus chr 10:17, 27 June 2010 (CEST)
I think that application names are always bolded for docbook, so we may have to live with that. Certainly it was on the list that blueck and yurchor gave me. One place I do hope to remove bold typeface is on links. Currently the links are not sufficiently visible without bold, but when the new theme is complete (it's well on the way, I believe) they will have better contrast. It may be time to start removing them now. --annew 13:37, 27 June 2010 (CEST)

Links to subsections

There seems to be a problem with links to different sections of a page. On Glossary towards the top of the page there is a link to Glossary#Virtual Desktops (written simply as [[#Virtual Desktops|''Virtual Desktops'']]) - klicking on that has no effect. I haven't checked the other internal links on the Glossary page, but have observed the same problem in the Danish translation. --Claus chr 11:51, 25 June 2010 (CEST)

The section markup had been removed from the Glossary page. It has been replaced, so they should work again now. --annew 20:26, 25 June 2010 (CEST)
Yes. I found a pair of typos, which probably go way back, so now they all work. Thanks. --Claus chr 10:02, 26 June 2010 (CEST)

Breakage Policy

If someone for some reason break the translations in GNOME, Fedora, and Debian, this person have to unfuzzy all the translations that have been done, if the changes are just formatting, better modules composition, or something like this. Such a policy prevent "mad heads" from changing too much at once.

What do you think about pursuing this policy here? --Yurchor 07:23, 28 June 2010 (CEST)

Recently a feature was added that allows for minor changes to not be fuzzied. Keeping formatting out of the translatable content will also help a lot here to prevent this. Unfortunately a whole lot of pages were already tagged for translation before there was clarity on proper tagging. See next topic for an update on this. siebrand 10:34, 28 June 2010 (CEST)

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.