Don't use conpherence with me, I won't read nor reply. Instead write me by email or my user talk on mediawiki.org.
Thu, Aug 16
Wed, Aug 15
(As noted in code review, this request is currently invalid.)
@Nemo_bis: It is irrelevant which software is used to show a string on the website.
Tue, Aug 14
Mon, Aug 13
If there are not any, what's holding this?
Sun, Aug 12
The "legacy" extensions could just be removed from the group without creating another one. Skins should not be conflated with "legacy": not only the skin is arguably the most important part of the interface to translate for those who use it, but the statistics about usage are not reliable due to a database data loss some time ago, and at any rate the relevant statistic would be by language preference and not by wiki.
Sat, Aug 11
This task is effectively a blocker for nearly all the other bugs in this component, so it's hard to understand how it can possibly be considered lower priority.
Thu, Aug 9
Thank you, I saw that yesterday and it's an improvement. Personally I was a bit surprised at first by the literal mention of MailChimp, I envisaged something like "a third party hosted in USA". But I see why a direct, concise and matter-of-fact wording can be preferable.
Wed, Aug 8
Thanks! :-) Looks like a clean solution.
Awangba has made multiple edits https://translatewiki.net/w/i.php?title=MediaWiki%3ABabel-5%2Fmni&type=revision&diff=8259167&oldid=8259162, which perhaps caused warnings with the message checker because of missing parameters. $1 is now present as expected, but the word "professional" needs to be translated.
Tue, Aug 7
To me it still seems the easiest solution would be to put this on a separate wiki.
Mon, Aug 6
Fri, Aug 3
By the way, the HTML is:
Thu, Aug 2
What do you mean by "participatory"?
The message above might refer to https://lists.wikimedia.org/pipermail/wikimedia-l/2018-August/090828.html
So the WMF website intentionally mischaracterises the OTRS queues? Where do you suggest to discuss this problem, given you closed the ticket?
A stylistic decision was made to use an inconsistent style?
Sure, after three page downs. Updating summary.
Can one read something more somewhere to understand the decision?
"Strategic", no less. Where is this strategy documented?
Sure, that's fine. At some point I'll take care of investigating the reasons for this and documenting them in the expected places.
Invalid response: people expect more from Wikimedia.
Possible duplicate of T200742
But it has no clue that it does.
An explanation is expected on https://meta.wikimedia.org/wiki/FLOSS-Exchange
Which only makes the bug worse.
There's nothing about the website. Stop abusing the "stalled" status for tasks which do not fit the definition.
Your distinction is artificial and has no basis in praxis.
Both questions are answered in the subject: "out of reach" is the problem, "reach" is the objective.
"New developers" is literally for people new to development. Our main target for technical contributions is https://www.mediawiki.org/wiki/How_to_contribute .
Thank you all for the investigation. The amount of indexed URLs seems worth acting on. Working on the sitemap might not be the ultimate solution but seems a good idea to me, because it's something we can use more generally (e.g. ArticlePlaceholder, T158506).
Thu, Jul 26
It's ok to follow the Django format, which is shared by several other projects. It would be good to clarify whether you have any support for grammatical gender or plural: translators will have questions and suggestions when they encounter some message which can't be translated correctly (for instance those which may depend
Fri, Jul 20
status.wikimedia.org has indeed no usefulness whatsoever: #wikimedia-tech on Freenode is our only real venue to report system status. The larger issue has been discussed at T22079.
Thu, Jul 19
Giving a fatal to the target users is hardly an improvement, so it would be fine to just revert the recent Babel change.
Jul 15 2018
Most of those features seem unlikely to be implemented in Huggle. As of now, the only thing Huggle may provide is the ability to add the "delete" tag, but if you need it so often then I may just make you sysop. Usually deletion is not used much on translatewiki.net because it's of little use for messages (it has no effect unless you delete a translation before it's exported at the end of the day).
If this is an offer for an unpaid internship of sorts, it might be helpful to state so explicitly.
Jul 13 2018
It's not very clear what it means to "enable Huggle" on a wiki like translatewiki.net. When I look at https://www.mediawiki.org/wiki/Manual:Huggle/Deploying and https://www.mediawiki.org/wiki/Manual:Huggle/Configuration , I see some 99 % of things which are irrelevant for translatewiki.net. Is it possible to disable any and all templates, edit summaries, regexes, scores, admin-related tools, report pages and talk page messages, so that other users do not notice any difference or "alien" practice? If it's just a different tool to perform the same edits, of course as translatewiki.net staff we don't have any objection.
Jul 12 2018
I would decline this extension request. If the point is to simplify the installation of requirements needed by Kiwix etc., that's more of a Parsoid project.
I agree that this task is currently too vague for a newcomer to address, but I can try and help work with interested users to define some specifications, if someone is especially interested in the topic.