Test/hi
This page is only for testing page translation feature.
Note
Documentation
Page translation feature allows controlled translation of wiki pages into other languages. In other words the content of each translation should be about equal to the source page. The source page is split into sections or paragraphs, each of which are translated individually. Also changes are tracked in the paragraph level. These paragraphs are translated using Special:Translate, which provides the common features known from message translation: display of translations in other languages, message documentation. This page is also accessible from Special:PageTranslation or Special:LanguageStats. A new feature currently unique to the page translation is a difference display of changed messages.
Test
Something else
A cat walks. How to use #-links with the translation system: Get Hot New Stuff
Images in paragraphs
I want to investigate how images can be places in the middle of paragraphs without causing the imfamous shortening of the first line after the image:
Here we just have the image code between two lines of text with no blank lines in between. This should keep the whole paragraph in one translation unit but look exceedingly ugly! The code for this image was [[Image:Kde440-desktop.jpg|400px|center]]. In fact the rule is that the placement parameter must be first, so [[Image:Kde440-desktop.jpg|center|400px]] gives a different result:
. In fact the rule is that the placement parameter must be first, so [[Image:Kde440-desktop.jpg|center|400px]] should be centered. It seems the stylesheet is breaking it in some way. It doesn't look ugly, though. Can anyone explain why? Perhaps it has to do with the options used. [[Image:Kde440-desktop.jpg|thumb|400px]] This time I used the 'thumb' option. How does that look? Is the line shortened now? Yes it is, so it would appear, that the problem is caused by the 'thumb' option. The code for this image was <nowiki>[[Image:Kde440-desktop.jpg|thumb|400px]].
No, the problem is caused by the lack of vertical space.
I'll just make one more paragraph to see what happens if no options at all are given (other than size):
This doesn't look right, either. Even if the image is wide enough to fill the whole line (and so avoid text aligned with the bottom of the image) there is still the problem with to little vertical spacing between text and image. The code for this image was [[Image:Kde440-desktop.jpg|400px]].
Can we conclude, that future guidlines for writers should specify, that images appearing in between text sections should never have the 'thumb' option selected? It seems that this would be a good idea. It also seems, that if the image appears in the middle of a paragraph it should have the 'center' option selected.
No, definitely not. There are a number of pages where a screenshot showing an overview is 300px or so wide, but the reader needs to consult the full-size image when studying a new concept. The spacing problems need to be resolved in other ways. Pages linked from User:Pipesmoker#Test_and_Debug_Pages may be helpful here.
Smileys
The standard smiley image is too large. It pushes lines apart, which doesn't look good. It should be made smaller. I'll try to find the proper size 
. This it how it looks when nothing is done. On my display it is far too big. If I specify a size of 11px, this is how it looks: . Much better, now the size of the smiley is about the same as a capital letter (it would look even better if it could be lowered 1 or 2px). It could be larger without pushing lines apart - here is a 15px sized smiley (actually I believe this line has been lowered just a bit, but maybe not too much? We did try using this image, but lack of consistency did cause some problems.
Of course it would be better to use a template so that writers would not need to worry about these details . The template Template:Smiley is just a simple code snippet. Perhaps it can be expanded to allow for different browser settings of font size, if that information could be captured inside a template. The template is the preferred option, and scaling it would be very nice.
Above all, we must avoid using text smileys, as translators then meet "unmatched pairs of brackets" problems.
Splitting bulleted lists in two translation units
- first
- second
- third
- fourth
Apparently it is possible to split a bulleted list in two translation units. Special:myLanguage/Tasks_and_Tools
Nested lists: Numbered:
- First main item
- First sub item
- Second sub item
- Second main item
- Third main item
- Third sub item
And now - items with two sections
- A translation page is constructed automatically form translated paragraphs, using the source page as model. Each translation page is assigned a completion percentage, which is calculated from the translated paragraphs, and decreased if those translations are out of date. Outdated translations are also highlighted.
A translation page is constructed automatically form translated paragraphs, using the source page as model. Each translation page is assigned a completion percentage, which is calculated from the translated paragraphs, and decreased if those translations are out of date. Outdated translations are also highlighted.
- A translation page is constructed automatically form translated paragraphs, using the source page as model. Each translation page is assigned a completion percentage, which is calculated from the translated paragraphs, and decreased if those translations are out of date. Outdated translations are also highlighted.
A translation page is constructed automatically form translated paragraphs, using the source page as model. Each translation page is assigned a completion percentage, which is calculated from the translated paragraphs, and decreased if those translations are out of date. Outdated translations are also highlighted.
A Table
| Jumping around in code | |
|---|---|
| Ctrl+Alt+O | Quick open file: enter part of a filename and select among all the files in the current session's projects' directory trees that match the string; the file will then be opened |
| Ctrl+Alt+C | Quick open class: enter part of a class name and select among all class names that match; the cursor will then jump to the class declaration |
| Ctrl+Alt+M | Quick open function: enter part of a (member) function name and select among all names that match; note that the list shows both declarations and definitions and the cursor will then jump to the selected item |
| Other things | |
| Ctrl+_ | Collapse one level: remove this block from view, for example if you want to focus on the bigger picture within a function |
| Ctrl++ | Expand one level: undo the collapsing |
Variables
The translate extension page describes the use of variables. They could be be used for version numbers and the like. You write
< tvar|variable>value</> (without the space character after the opening <, off course) inside a translatable section. To translators it will appear as $variable.
The nice thing about this is, that when the values changes, the changed value propagates to all translations automatically. Translators don't have to do anything, and the translations ar not marked as fuzzy. To make this happen, the page still has to be marked for translation, and affected units must be ticked to not affect translations. It is almost guaranteed that this will be forgotten.
Example: Writing
The current version of eKsampleApp is < tvar|version>0.0.1</>.
displays this
The current version of eKsampleApp is 0.0.1.
Unfortunately, currently the $variable is only availlable in the translated pages. If extended, this feature might be really useful, fx when an application changes name.
Note: The tvar tag seems to be processed quite early in the parsing, so it is OK to use it in templates and even between nowiki tags.
Translating variables
This might go to Translate a Page, fx immediately after Info-boxes.
A variable is a of the form $name. It is defined in the original page as < tvar|name>value</> (without the space character after the opening <, off course). Whenever you write $name in your translation, the value given in the original page will be inserted. If the value in the original page changes at a later time, that change will automatically be applied to your translation as well without the need for you to do anything.
Using variables
This might go somewhere on Toolbox
If you have something in your page that doesn't need to be translated, you can use a variable; this can be useful for things like version numbers. Lets say you are writing the page for the application eKsampleApp and want to include information on the current version number. You can then write something like this in an ordinary paragraph (ie. inside a translation unit):
The current version of eKsampleApp is < tvar|version>0.0.1</>.
(without the space character after the <, off course). This will display
The current version of eKsampleApp is 0.0.1.
Instead of the current version number, translators will see the variable $version, which displays the version number. Then, when the version number is changed, the change automatically appears on the translated pages. The change still needs to be marked for translation, but if the affected section is ticked to not affect translations the translators won't need to do anything.
Linking with templates
Lets define a template {{UB}}, which produces http://userbase.kde.org . Now lets try {{UB}}/Quick Start, which gives http://userbase.kde.org /Quick_Start. Now lets try [{{UB}}]: [http://userbase.kde.org ] and [{{UB}}/Quick_Start Quick Start]: [http://userbase.kde.org /Quick_Start Quick Start]
Information
Testing Special:myLanguage links. [[{{Plasma}}|A nice page]] gives [[Special:myLanguage/Plasma
|A nice page]] and [[{{Plasma}}/Panels|An other page]] gives [[Special:myLanguage/Plasma
/Panels|An other page]].
Note on trailing slashes: For external links like http://userbase.kde.org
it is OK to have a trailing slash in the template, but for internal links it only works, if the template is only going to be used as a path prefix: Links of the form [[Plasma/]] do not work.
Template for Application Lists
A Headline
This is a short line of description. It should normally not be more than one or two sentences.
Same icon, different link. This is just for testing purposes.
Another Headline
This is a short line of description. It should normally not be more than one or two sentences.
Same icon, different link. This is just for testing purposes.
That's all, folks!