Talk:Issues and features
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Multiple translations at same time | 3 | 12:46, 28 October 2012 |
Saving a translation as draft | 3 | 15:00, 3 June 2011 |
Commit | 0 | 14:27, 28 December 2010 |
CSS Customization and numbering system | 16 | 03:03, 23 September 2010 |
More information needed or uncertain issues | 0 | 08:06, 8 July 2010 |
With current interface (which shows translation field inside the table), I think an option to open and save multiple message there will be useful to avoid clicking each message link. Just got the idea from Launchpad. :-)
Use the shortcut keys.
Oh.. shortcut keys. But I was suggesting another kind of feature. I knew, special page or magic word translation pages are doing a simillar actions so I thought this may be possible. My bad. The Developer priorities may be different. ;-)
Yes, they are. See mw:Translation_UX/Specification for near future plans.
Is there any option to save partially completed translation as a draft? If no, adding such a feature will be useful while translating big Messages.
We could probably use Extension:Draft which works beautifully in my local wiki. It is at least a means to keep some unnecessary stuff out of the revision history and reduce the text database size a bit.
We could try it out, but it would need to be integrated into the interface somehow.
Hi, i think customization of CSS(and javascipt) is needed for translators. For example we are using other type of number in persian(fa,mzn,glk) language (۱۲۳۴۵۶۷۸۹۰) instead (1234567890), also ckb and some other languages use other type of number (١٢٣٤٥٦٧٨٩٠) (that have bit differences). Mediawiki parser functions have not problem for produce our numbers(in persian wiki {{formatnum:123}}=>۱۲۳) but html <ol> tag cannot produce our number well(without local patches same [1][2]), persian and arabic-indic numbering is a new feature that supported in CSS3 that already are supported in firefox with -moz- prefix and in webkit browsers(chrome, safari and ...) without any prefix but also it is easy to support this numbers in other browsers with javascript!
I provided this example of list-style-type usings, that you can see them correctly in firefox, chrome, safari now. Default numbring:
- 1
- 2
- 3
- 4
- 5
- 6
Persian numbring:
- ۱
- ۲
- ۳
- ۴
- ۵
- ۶
Arabic-indic numbring: (same above but is a bit diffrent)
- ١
- ٢
- ٣
- ٤
- ٥
- ٦
Code:
<ol><li>1</li><li>2</li><li>3</li><li>4</li><li>5</li><li>6</li></ol> <ol style="list-style-type:-moz-persian; list-style-type:persian;"><li>۱</li><li>۲</li><li>۳</li><li>۴</li><li>۵</li><li>۶</li></ol> <ol style="list-style-type:-moz-arabic-indic; list-style-type:arabic-indic;"><li>١</li><li>٢</li><li>٣</li><li>٤</li><li>٥</li><li>٦</li></ol>
Thanks
Interesting feature, but I think it should depend on the locale users have set. Any opinions if this should be a core feature or that it should be added with an extension (UserLangCSS)? Niklas?
It will be better if this option added in core's language supports(I think both CSS3 and Javascript modification is needed for that).
for example users in our wiki must using this ۱۲۳۴... number, but when they used # for making numbered list(before my patch), their result was 1. 2. 3. 4. .... I think this feature is needed for all persian mediawiki wikis.(specialy when result of {{formatnum:123}} is ۱۲۳ in this wikis!)
seems there is not a good javascript way, without converting ol tag to other thing! curently I found a javascript code that converted "ol" to "span" for showing numbers correctly! so CSS3 is only remaining way for this job.
I think ability of modifying a CSS for translators may sufficient in this case. (mediawiki:localtrans.css or something else)
For now it's easier to add them manually in the core stylesheets (probably restricted just to content with suitable language code).
adding on this? MediaWiki:Common.css/fa, MediaWiki:Common.css/mzn, MediaWiki:Common.css/glk and MediaWiki:Common.css/ckb
Waiting for Niklas with a final recommendation, but the mentioned CSS pages are exported, so please *DO NOT CHANGE THOSE*.
AryehGregor> Nikerabbit, the CSS :lang() selector is probably supported by all UAs that support funny numbering schemes, so rules like li:lang(fa) { list-style-type: persian } in shared.css seem like the best way to do it.
@Nike: User:Ebraminio/number seems good for now.
Added the following rules for testing:
/* Localised ordered list numbering for some languages */
ol:lang(bcc) li,
ol:lang(bqi) li,
ol:lang(fa) li,
ol:lang(glk) li,
ol:lang(kk-arab) li,
ol:lang(mzn) li {
list-style-type: -moz-persian;
list-style-type: persian;
}
ol:lang(ckb-arab) li {
list-style-type: -moz-arabic-indic;
list-style-type: arabic-indic;
}
great, this code working well for me. i had not knowledge about this selector. why you don't put it for other languages that i listed? I exported that data from mediawiki localization codes.
Just testing if there any unseen problems with it. How did you come up with ckb-arab? There doesn't seem to be such language?
« P2 FEATURE: add "\n" to the problematic checks for FreeCol. In MediaWiki a newline does not mean anything, in FreeCol it does and is exported as "\n". Number of "\n" in source should be equal to that in destination. »
- Sorry for reposting this here, but it was reverted, despite the page design looked like a discussion itself given its presentation and the title of the section, which is a call for discussion, starting from a personnal creation !
- You wrote:
- « In MediaWiki a newline does not mean anything » : of course this is wrong !!!
- And this is even the case in plain HTML, with preformated texts that change the interpretation of whitespace, but even elsewhere this can be controled in Javascript (see CSS property 'white-space: pre|nowrap|wrapped'), and in XML (including XHTML) there is also the pseudo-attribute "xml:whitespace=" to change the default (where all whitespaces are considered equal, converted to regular SPACE, then compressed and trimmed).
- MediaWiki makes even more use of newlines than HTML or XML, as it uses it as part of its syntax for recognizing special characters at the beginning of lines: for numbered/bulletted lists (with "#" and "*"), tables (with "{|" and "|}", table captions (with "|+"), table rows (with "|-"), table data/header cells (with "|" or "!"), definition lists (with ";" and ":"), and blockquotes (with ":" too ; blockquotes are recognized with the same special character if there's no prior line starting with ";" for a defined term and this line contains no ":")
- MediaWiki also uses the exact number of newlines to make distinctions between a continuation of a text span on the next source line, and a true line break creating a new paragraph (if there are n+1 newlines, MediaWiki creates exactly n new paragraphs if the next character is not one of the special ones, and n-1 paragraphs if these newlines are followed by a special character).
- The way the newlines are counted are slightly mofified within parameters of Parser Functions and template invokations (because trimming is used on the source text delimited by braces and pipes), or within the text returned by a transcluded template (where only the last newline in its source is dropped), but they are still not completely ignored as well.
- And outside of table cells and captions a space leading on a line will be used to recognize a preformated line
- MediaWiki however will trim the contents of all the rest, after it has resolved the special meanings above. Only at this level of parsing, newlines take no more roles.
- I'm sure that instead you really meant HTML and not MediaWiki (but note that even HTML, XHTML and XML include specific interpretations of newlines, distinct from other whitespaces).
Anyway if you problem is related to the apparent impossibility of Mediawiki of preserving all the newlines present in a resource, the simplest way to solve the problem is to use « <nowiki/>
» at start and at end of the resource being edited when there are wanted leading newlines or trailing newlines. Because MediaWiki preserves all the other internal newlines, and only trims the leading and trailing newlines (the empty 'nowiki' element prevents Mediawiki to do that, but generates nothing by itself). And this could solve the problem you have with some Freecol resources (or any other projects in their .po/.pot files for GetText) that use leading or trailing '\n' in their messages.
Note that this conversion from .po/.pot format to Wiki of resources, can perfectly be bijective, even if this requires escaping some newlines using an empty 'nowiki' element. And this is even true if the .po/.pot file contains the string <nowiki/>
at start and/or end of a message to translate, that you can also escape by adding another leading and/or trailing one, within MediaWiki. This case, even if it looks very tricky to resove, however should most probably be exceptional or inexistant in practice.