Tue, Jul 3
Mon, Jul 2
Now I note an odd behaviour related to this edit summary. Here revision differences show that the only automatic template replacement was made in revision that has "Imported with FileImporter..." edit summary, not in the one that has edit summary about replacement.
I don't know about the usefulness of this config section, but why not add information template from scratch? Adding it along with two section headers, even if none of it is present on source page, would seem rather straightforward. Some wikis don't have information template set up, and it seems section headers weren't used for older uploads, but these are part of standard page layout on Commons and they should be added anyways. Both CommonsHelper and FTCG also always add these. What probably isn't straightforward is whether information template, if created from scratch, should be auto-filled with some data. (For instance I doubt if using upload time for date field is really wanted, even though both of these older tools for some cases do it.)
Currently prefilled edit summary for this is in importer's interface language. I suppose wiki content language (English for Commons) would be preferrable instead.
Fri, Jun 29
Using link like [[wikt:de:Paris]] on Commons seems to bring me to the right place (German Wiktionary), eventhough technically it's redirected via English Wiktionary. That kind of links seem to be used for edit summaries for imports done via Special:Import already, e.g. here. Is that problematic?
Wed, Jun 27
To be clear, you mean that cleartables mentioned above wouldn't be deployed? If so, then couldn't we still look for some other solution? (I still wonder what solution WIWOSM uses.) Waterway relations with wikidata tag are considerably more common (currently 8692 uses) than other special type relations, so it would be nice to see at least that supported, at least in long-term.
May 11 2018
Apr 20 2018
Aug 20 2017
It seems that some sort of generalization algorithm is applied to all maplink/mapframe external data on Wikimedia side, including polygons of geoshape type, and for longer features it's just easier to spot. For example border segment of this object (Q990542) matches river curvature, but maplink/mapframe shows a zig-zag line that departs from river curvature (figure 1), unlike WIWOSM (figure 2). I hope this line generalization is not needed for performance reasons and can be dropped easily.
Aug 17 2017
Whatever caused this, given syntax seems to work again on prod wikis.
Jul 31 2017
It's from the above patch for which I was translating new messages on translatewiki.net.
Message 'ores-rcfilters-goodfaith-bad-desc-high' currently says "With medium accuracy...". Message name and analogous 'damaging' filter message suggest that it intends to say "With high accuracy..." instead.
May 21 2017
Three out of four messages named above were introduced along with centralauth-log-entry-chgstatus in 823ef3e5e109. First ones are intended to be used as part of the latter one, or at least that's what the docs suggest.
May 5 2017
Well, failure in the SAL isn't the only reason why translations sometimes won't go through in a timely manner. As noted above sometimes the problem is elsewhere, or regarding certain interface text delay could be intentional (I usually suspect the latter). Most translators probably don't know where to check any of that. And of course, if the interface text isn't highly visible, then its translation not coming through may go unnoticed too by translators since they are not expected to come back each time they have translated something to see if updating went smoothly.
May 4 2017
It may be that it wasn't reported sooner because translators are used to complications with the updating process and it's hard to tell whether it's broken, or there's yet another temporary outage, or delay to daily update is intentional due to message definition update or some other special condition related to certain message or repo. This time I looked into it a little and reported it, but usually I'm just patient. I expect interface texts to be updated in a timely manner though. In any case, thanks for fixing it.
Seems to work again. Thank you!
Apr 24 2017
Apr 13 2017
It's a tab text change which can be done via translatewiki.net too.
Apr 6 2017
Mar 27 2017
I understand what RTL support is for. I only suggested different button text, not different functionality.
Technically it may be about changing direction, not alignment, but visually it doesn't look like that. Last full stop of the paragraph jumps, but other than that the reading direction remains the same and most notable change visually is the alignment change.
New button text "View as left-to-right" (or the other way around) is quite confusing as visually it only changes text alignment not direction. Perhaps say "Type left-to-right" or "Switch to left-to-right typing" or something like that?
Jan 25 2017
Dec 18 2016
Dec 17 2016
Yes, this should be how it works.
Why I modified your patch: messages need to be defined in source (en.json) to be picked up for translation via translatewiki.net. Translations for specific languages can be committed directly to repo, but it's not necessary. Current Estonian translation is not ok as it doesn't follow the English source because the autopatrollers group name itself is custom (i.e. not following the English source) on Estonian Wikipedia. So these texts using custom group name still need to be provided locally as well.
Dec 16 2016
It's not defined as a message in any message group (or i18n file) and hence cannot be translated via translatewiki.net. Text for this message needs to be provided locally.
Nov 27 2016
Sep 27 2016
Apr 10 2016
Relates to T124522. Changing how the "pagetext" class is applied would probably fix this other bug too.
Mar 27 2016
Mar 25 2016
I note that variables in the following message are percents not numbers of pages as it should be.
$1 validated pages, $2 only proofread pages and $3 not proofread pages
E.g. if there's 1 proofread page and 4 not proofread pages, then it reads as "20 proofread pages and 80 not proofread pages".
Oct 10 2015
Sep 17 2015
Aug 17 2015
Thanks for looking into it. Another tiny problem which I note: the word "and" between two licenses isn't translated when using interface language other than English.
Aug 15 2015
So, if I try editing here, then after clicking "Next" I still see "license" not "licenses" even though there are two licenses. I see that the message itself has been adjusted to using PLURAL, but it doesn't seem to work.
May 31 2015
May 21 2015
May 15 2015
May 14 2015
Apr 29 2015
I understand that here it's intended to omit the year from date. It seems that Echo fails to extract day and month format from custom date formats properly if the year is omitted. E.g. for Estonian localization (et) there should be dot after day number, while Echo shows it without dot just like in English by only translating the month name. However there is one custom (non-default) date format where month is a roman number (29. IV 2015) and which forces Echo to show the year as well and for that format it shows the dot too. Maybe a simple solution would be to never omit the year? It's odd anyways that the year is omitted while notifications from different years are listed.
Mar 29 2015
Mar 28 2015
Mar 18 2015
Mar 3 2015
I wonder if the wanted behaviour is similar to Commons file description pages which are transcluded on local wikis and where links are still relative to Commons (except for comment line links). Could it be implemented the same way?