As far as I know, most common (and "expected", from the user point of view) approch when implementing FTI solutions in Slovak-centered projects, is to normalize all latin variants of each char into it's plain ASCII equivalent. The resulting side-effect of (search) equivalence of words like mäso/maso is a minor one in Slovak (and users can solve this by iterating through search results, where term matches are presented in their original, non-normalized form).
May 31 2019
As for latin chars with diacritics, maybe even a simple iconv/recode-based ASCII translit term normalization (both on indexing and lookup side) would be sufficient for Slovak and other latin-based alphabets:
Jan 15 2019
Even in case thers's no format value in TemplateData (or no TemplateData / no doc for given tamplate at all), VE should not change block template markup into inline (and vice-versa). It should not be that hard to infer inline/block format from actual markup during parsing (witespace containing newline before/after argument separators, maybe some simple RE based heuristics).
Jul 18 2017
This is intentional prioritisation for the billion users of Vector (as the default skin on Wikimedia wikis) against the thousands of users of Monobook (which isn't).
@Whatamidoing-WMF I don't expect them to look the same. What I do expect, is that the accessibility aspects (sizes and contrasts of relevant widgets, in this case) would get improved in the same way, regardless of a skin. Otherwise, there is no real benefit of change like this for non-vector users.
Jul 11 2017
Under Monobook still no progress...
- no OOjs UI "accessible" styling of inputs (standard tiny checkboxes)
- strange bathroom-green gradient publish button, inconsistent with blue-gray skin visual
- large vertical indent between summary and checkboxes
May 1 2016
Mar 11 2016
Dec 3 2015
I think your request is to make #2 more robust to affect _all_ UI elements. Is this correct or were you thinking of a fourth language option?
Nov 30 2015
@Dbrant There are cases, where non-english users tend to (or have to) keep default english system-wide locale:
- corporate policy / locked settings
- wrong quality system localization (for their native language)
- wrong quality UI localization or a malfunction of some key app (which, too, does not provide independent UI lang switching...)
BUT at the same time would prefer some other Wikipedia-Android app locale, if available.
Nov 28 2015
Nov 25 2015
OK, that makes sense (and is kind of symmetrical, in its own way), but to be true, somehow I've hoped, that Flow is implemented in a way, backward compatible with wikitext content format, so that common things, like diffs over multiple revisions, diffs from watchlist/RC, markup operations over single or multiple comments (copying, moving, merging, quoting/reusing on wikimarkup level) and particularly, the ability of posting comments using both approaches will be preserved. Sadly, that seems not to be the case.
Thanks for the explanation, Matthias. But then - is there any sane way for Flow-enabled and non Flow-enabled users to discuss/collaborate on the same talk page? If there's no such way, I don't really understand the purpose of proposed Flow opt-in/opt-out games. NonFlow-ers won't be able to discuss on talk pages, created by Flow-ers (while Flow-ers will still be able to discuss on classic wiki talk pages), which is quite asymmetric outcome and it will, de facto, force all to use Flow...
Would it be possible to set $wgFlowContentFormat to "wikitext", to be able to test Flow in the way, that is compatible with non-Flow discussants?
Jun 8 2015
Hello Arial, thanks for explaining.
I've filled this one at the end of May, related to skwiki:
https://phabricator.wikimedia.org/T100877, with I believe was related to
this issue. Not that it has gained any attention at all... :)
Seems to be solved, all skwiki dumps up to date, as of June 05.
Jun 6 2015
Hi Kolossos, nice to hear from someone familiar with the thing... :)
No change after restart this time, permanent 502 Bad Gateway response for
Really no way to fix?
Jun 5 2015
@yuvipanda: who actually is a maintainer of the tool?
Jun 4 2015
24+ hour outage, can anyone have a look and resume normal op, if possible?
Any thoughts? Pages/articles/histories at /skwiki/latest/ still of April
May 30 2015
May 14 2015
Well, I was doing the same in parallel... :)
May 5 2015
Nice, but it would be more relevant to monitor actual availability of each
particular service (tool) alone. The availability of kmlexport was < 90%
during last 24h, I guess. And even worse during week 17 (April 20 - 26).
Plenty of dropouts last two days: http://tools.freeside.sk/monitor/http-
Apr 15 2015
8+ hr downtime right now...
Mar 23 2015
And 4+ hour outage right now: http://tools.freeside.sk/monitor/http-
Mar 22 2015
After 4 days of continuous operation since the limit update advertised,
some outages today, the longest one being ~90 min:
Mar 17 2015
Right now it seems to be down again.