Talk:Translation Workflow

First Observations

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

Not sure what you mean here. The 'link|title/description format is preferred. Is the problem solved or still existing? If so, can you describe more. --annew 20:52, 28 June 2010 (CEST)

I haven't seen this problem lately, so I assume that it was solved by the bug fix. --Claus chr 22:17, 28 June 2010 (CEST)

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)

(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 http://translatewiki.net/wiki/Issues_and_features#Page_translation . 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)

Images

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 translatewiki.net. – 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)

Templates

Some templates such as {{community-app}} exists in translated versions like {{community-app_da}}. They should be included in the translation units like regular text unless the translation system can somehow be made template aware. --Claus chr 17:22, 28 June 2010 (CEST)

The above remark may be mistaken. At least in some cases the template has been included in the translation unit, only the translation system didn't show its precense (at least not clearly enough for me to notice). However, there is another problem: the {{Community-app-footnote}} template seems allways to be separated form the category lines by a blank line and thus does not belong to any translation unit. The easiest solution would seem to be removing the blank line unless that messes up the display. Otherwise, perhaps we should have a separate translation unit for this template, when it is present? --Claus chr 19:33, 28 June 2010 (CEST)

I modified some pages to include the templates, changes not yet marked for translation. I think this is the reason for your perplexity.--Caig 20:21, 28 June 2010 (CEST)

Are You saying, that templates are treated as part of the regular text and so not excluded from translation? If so, I'll just wait for them to be marked and deal with them then. --Claus chr 22:22, 28 June 2010 (CEST)