Talk:Issues and features

Jump to navigation Jump to search


Thread titleRepliesLast modified
Multiple translations at same time312:46, 28 October 2012
Saving a translation as draft315:00, 3 June 2011
Commit014:27, 28 December 2010
CSS Customization and numbering system1603:03, 23 September 2010
More information needed or uncertain issues008:06, 8 July 2010

Multiple translations at same time

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

Praveenp (talk)13:30, 25 October 2012

Use the shortcut keys.

Siebrand13:11, 27 October 2012

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

Praveenp (talk)01:19, 28 October 2012

Yes, they are. See mw:Translation_UX/Specification for near future plans.

Siebrand12:46, 28 October 2012

Saving a translation as draft

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.

Praveenp16:13, 24 May 2011

Prepend the message with !!FUZZY!!, but just be aware that the translation may still be used.

Nike19:01, 24 May 2011

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.

Purodha Blissenbach12:56, 3 June 2011

We could try it out, but it would need to be integrated into the interface somehow.

Nike15:00, 3 June 2011
A thread, Thread:Talk:Issues and features/Commit, was moved from here to Support. This move was made by Nike (talk | contribs) on 28 December 2010 at 14:27.

CSS Customization and numbering system

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. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6

Persian numbring:

  1. ۱
  2. ۲
  3. ۳
  4. ۴
  5. ۵
  6. ۶

Arabic-indic numbring: (same above but is a bit diffrent)

  1. ١
  2. ٢
  3. ٣
  4. ٤
  5. ٥
  6. ٦


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


ebraminiotalk15:27, 16 August 2010

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?

Siebrand15:58, 16 August 2010

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!)

ebraminiotalk16:46, 16 August 2010

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)

ebraminiotalk17:35, 16 August 2010
Edited by another user.
Last edit: 19:55, 16 August 2010

For now it's easier to add them manually in the core stylesheets (probably restricted just to content with suitable language code).

Nike18:44, 16 August 2010
ebraminiotalk09:42, 17 August 2010

Waiting for Niklas with a final recommendation, but the mentioned CSS pages are exported, so please *DO NOT CHANGE THOSE*.

Siebrand12:06, 17 August 2010

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.

Nike16:38, 31 August 2010

@Nike: User:Ebraminio/number seems good for now.

ebraminiotalk09:19, 3 September 2010
Edited by another user.
Last edit: 21:04, 13 September 2010

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;
Nike14:40, 13 September 2010

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.

ebraminiotalk20:45, 13 September 2010

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?

Nike14:54, 15 September 2010

Not anymore, but it was still there a few weeks ago.

Siebrand15:10, 15 September 2010

yes, please change ckb-arab to ckb,

if you want test your css code, you can test that on this page with this CSS:

ol:lang(ckb) li {
	list-style-type: decimal

this will turn over ۱۲۳۴۵... to 12345... (and this confirm that your CSS is working great:) )

ebraminiotalk07:09, 17 September 2010

More information needed or uncertain issues

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

Verdy p07:39, 8 July 2010