Difference between revisions of "Talk:Translation Workflow"

(→‎First Observations: Removed conversation now ported to LQ)
(→‎(Fixed) Translation sections in categories: Removed obsolete conversation)
Line 1: Line 1:
== (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 [http://userbase.kde.org/Category:Per_iniziare_(it) this]. I think readers can be confused a bit.--[[User:Caig|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. --[[User:Nilli|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. --[[User:Annew|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 :-) --[[User:Annew|annew]] 14:23, 14 June 2010 (CEST)
::::Really wonderful! --[[User:Caig|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! --[[User:Nilli|Nilli]] 21:50, 14 June 2010 (CEST)
:::::Yep, I found a maintenance script that fixed them. – [[User:Nikerabbit|Nikerabbit]] 21:53, 14 June 2010 (CEST)

Revision as of 03:52, 7 July 2010


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)


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)
Yes. When I translated the Applications/something pages, only one template was included in the translatable text. I added the others, now they seem included in the source, but are not prepared for translation yet.--Caig 10:45, 29 June 2010 (CEST)
Until we get some concensus about the catalogue-like pages, Applications/whatever, I'd suggest that you don't do any more translations. We might mark some versions for translation so that you can see how the markup affects you, but don't do any work on those pages. Actually, if we stick to working on the Welcome page for experiments it should keep things more simple. Once we have concensus I'll apply it to all the catalogue pages then mark them for translation. We're trying to find ways to meet most needs without creating unnecessary work. --annew 12:35, 29 June 2010 (CEST)

This page was last edited on 7 July 2010, at 03:52. Content is available under Creative Commons License SA 4.0 unless otherwise noted.