Talk:Translation Workflow: Difference between revisions
No edit summary |
No edit summary |
||
Line 23: | Line 23: | ||
::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. --[[User:Claus chr|Claus chr]] 18:09, 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. --[[User:Claus chr|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. --[[User:Annew|annew]] 21:55, 10 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! 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. --[[User:Claus chr|Claus chr]] 19:43, 10 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! 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. --[[User:Claus chr|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. --[[User:Annew|annew]] 21:55, 10 June 2010 (CEST) |
Revision as of 19:55, 10 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. 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)
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)