CEE Technical Village Pump

To add a new technical request, click below

Start a new technical request

Help us to translate this header into your language!

Welcome to the CEE Technical Village Pump. This page is a central place where Wikimedia contributors and communities in the CEE region can submit technical requests and ask for help from experienced volunteers. Requests may relate to bots, templates, modules, gadgets, Toolforge, Wikidata, scripts, MassMessage, CentralNotice, APIs, or other technical issues connected to Wikimedia projects.
Types of requests	When posting a request
Bot and automation support Templates and Lua modules Toolforge and Cloud VPS Gadgets and user scripts Wikidata and API-related help MassMessage and CentralNotice Technical consultation for campaigns or events	Use a clear and specific section title Briefly explain the issue or request Include relevant links, screenshots, or error messages if relevant Mention the Wikimedia project or community involved Requests can be submitted in any language used within the CEE region. English is not required. Sign your request using ~~~~

Cannot submit my translation.

@Wikimedia, I translated this page but cannot submit my translation. Can you help me please? SunnyIvannie (talk) 09:45, 26 August 2026 (UTC)

If you're talking about the Ukrainian translation it seems to work. If your interface is in English, just append ?uselang=uk to see this page in Ukrainian. Strainu (talk) 10:05, 26 August 2026 (UTC)

Naming the Special: pages

I'd like to know how pages in the 'Special' namespace can be renamed on local Wikimedia projects. Specifically, I'd like to have the mess on the Slovene Wikipedia sorted out - most pages have their names localised (Posebno:PosebneStrani, Posebno:ZadnjeSpremembe...) but some do not (Posebno:Nearby, Posebno:AbuseFilter...). I asked our interface administrators but they didn't know how, either. —Upwinxp (talk) 12:00, 29 August 2026 (UTC)

Hello, Upwinxp. If I'm not mistaken, this could be requested in Phabricator. These pages cannot be moved, but aliases can be created. Other Wikipedians have already requested such changes: T421124.

Or, as stated here, you can use a developer account to submit the proposed code to Gerrit or use the Gerrit Patch Uploader.

Anyway, it would be great if someone else shared their opinion. Carbonaro. (talk) 13:25, 29 August 2026 (UTC)

P.S. You may see current aliases by running this API query. As pointed out, Specialpages has aliases PosebneStrani and SpecialPages, and Recentchanges has aliases ZadnjeSpremembe and RecentChanges. Carbonaro. (talk) 13:31, 29 August 2026 (UTC)

Create a Phabricator task with a list of localised titles, I will help you. Nemoralis (talk) 13:32, 29 August 2026 (UTC)

If you end up needing a code review (+2) on localizing them, feel free to ping me :) Msz2001 (talk) 13:49, 29 August 2026 (UTC)

The Special pages names/aliases are translated in deeper config files of MediaWiki. Just open a ticket in Phabricator like phab:T421124 preferably pointing to a local consensus. Geraki ^T_L 16:10, 29 August 2026 (UTC)

Thank you for all the answers. I'll prepare a list of aliases I'd propose introducing and discuss it with my fellow Wikipedians. Upwinxp (talk) 16:50, 29 August 2026 (UTC)

Feel free to ping me, I can help you. Veritas Sapientiae (talk | email) 03:49, 30 August 2026 (UTC)

Year format in Bulgarian Wikipedia

TL;DR:

1. Bulgarian Wikipedia has never had a consensus on whether years should be written as "2024 г." (short) or "2024 година" (long). Both are grammatically correct.
2. Experienced editors often engage in lame edit wars.
3. Is it technically possible to have a setting that allows each user to choose how years are rendered?
4. Other wikis have done something similar. Is this worth pursuing?

Hello, fellow Wikipedians,

Bulgarian Wikipedia has been stuck in a long dispute that internal mediation hasn't resolved.

We're a small community with around 20 active contributors. Over a long period, Bulgarian editors have been engaged in repeated edit wars over one simple question: should years be written as "2024 г." or "2024 година"? Both forms are grammatically correct in Bulgarian. Neither harms readability that much. Some editors argue abbreviations align with modern standards, while others feel full spelling is more accessible.

In reality, the problem isn't the style in particular, it's about what happens when editors with strong opinions start reverting each other. The discussion threads span hundreds of messages (see for example Качество и справедливост, Качество и справедливост 2.0, Качество и справедливост 3.0). Mediation has failed repeatedly. Unfortunately, the cycle continues because neither side feels heard, and more importantly, because every time someone makes a stylistic change, another person reverts it. No amount of polite reminders stops the pattern.

We've exhausted typical community mechanisms. Consensus-building discussions collapse into arguments. Arbitration would require judging behaviour rather than solving the content issue and nobody is willing to start the process anyway. New contributors watch experienced editors fight over grammar.

At this point, the conflict consumes more energy than it's worth, but implementing a rule won't work either – there will always be ways to bypass it.

Just for clarity, one recent example is this:

08:33, 17 July 2026	Article creation by user Божин Божинов
13:11, 17 July 2026	Formatting by user Nk, along with changing of style
14:26, 17 July 2026	Reverting to original style by user Carbonaro.
09:05, 18 July 2026	Revert by user Алиса Селезньова, stating that "Wikipedia has no article ownership"
16:28, 21 July 2026	Reverting to original style by user Carbonaro.
07:27, 22 July 2026	Revert by user Алиса Селезньова
08:21, 22 July 2026	Revert by user Carbonaro.
17:26, 22 July 2026	Revert by user Алиса Селезньова

Just to make things clear: This is for informational purposes only. We are not trying to decide who's right and who's wrong. We are trying to come up with a practical solution that may prevent further edit wars, regardless of the people involved.

Proposal

Before we start discussing this in our wiki, is a user setting technically feasible? Specifically: let each user, no matter if logged in or not, choose their preferred display format for years. When enabled, all instances would render according to that preference – "2024 г." for those who prefer the short form, and "2024 година" for those who don't. We have observed that a similar approach is used in Serbian Wikipedia, because Serbian uses two scripts: Cyrillic and Latin. Both have equal official status and are used interchangeably in everyday life.

How we will treat anonymous users:

1. The style is chosen at random.
2. The short form is used (as specified in CLDR, for example).
3. The short form is used on mobile, whereas the long form is used on desktop.
4. The long form is used.

This is subject to further discussion. It's about acknowledging that both are valid and letting individuals read the project their way while avoiding edit wars entirely.

First, is such a feature technically possible within MediaWiki? Second, do you know of other CEE or global wiki projects that have implemented similar policies that we can learn from?

We're asking for expert opinion on whether this deserves further pursuit. If nothing works, we can shift our focus to behavioural policies instead. If this isn't the right page for such inquiries, please accept our apologies.

We appreciate your input. Carbonaro. (talk) 12:40, 29 August 2026 (UTC)

FWIW, there's an ongoing discussion on Bulgarian Wikipedia here: bg:Уикипедия:Разговори#За „години“ и „г.“.
— Luchesar • T/C 14:46, 30 August 2026 (UTC)

For dates generated by MediaWiki, such as those shown on history pages and in diffs, this could be implemented using $dateFormats in the language-specific file. For example, see phab:T409013.

But for the article content, I am not sure. Maybe via a gadget? Nemoralis (talk) 13:31, 29 August 2026 (UTC)

The strings in question are those in the article content. We're exploring a server-side solution, not a gadget, mainly because the dates should be parsed before they're displayed to the user.

Concept

Currently, there is an "Appearance" section where users can choose text size, content width and colour (screenshot). I'm wondering if there's a possibility that another setting is added, for example "Date format", where users can choose their preferred date format.

How it might be carried out in the back-end:

1. A function matches all instances of ([0-9]{3,4}) (г\.|година), excluding sources, citations, links, categories, files, etc.
2. All instances are rendered according to the user's preference.
3. The text is then output to the user.

I'd like to emphasize that this is just an outline of how it might be handled, it is not a definitive example of best practice. I'm just discussing the idea to get some opinions and suggestions. I see that ttwiki, shwiki have adopted similar conventions, although the context differs slightly from ours. Carbonaro. (talk) 05:45, 30 August 2026 (UTC)

Doubtful you can have this done server side. Would be a bad idea for cache. On plwiki we have a similar problem, but we tend to resolve this by suggestion not change convention established in a given article. So more of a rough compromise then a solution.

What you could do is have a template {{г|1224|година}} that would then output ... г<span class="tpl-година">одина</span>. A gadget just adds .tpl-година {display:none}. The question is do you really want, to do that. Most of the easy cases could be handled by a bot adding the template for current articles. Other cases would need to be handled manually. Nux (talk) 15:59, 30 August 2026 (UTC)

I don’t think there’s a server-side solution, especially not for logged-out users (the HTML sent to logged-out users depends more on caching than that sent to logged-in users; trying to send different HTML based on preferences of logged-out users would kill performance). German Wikipedia can show dates depending on user preferences, but there are two major differences to your situation:

• The difference is geographical. Germans in Austria call January Jänner, Germans in Germany call it Januar. So the technical solution uses the regional language variant de-at, which you don’t have.
• There’s a clear default. All logged-out users as well as logged-in users who haven’t changed their preferences get the Germany variant.

Tacsipacsi (talk) 22:10, 30 August 2026 (UTC)

Thanks for sharing this. It's good to know that this problem isn't exclusive to us. Now I see why it isn't that easy. Adding templates would be a daunting task and nothing will stop users from not using them. Based on your experience, what methods are there to handle this? We're a small wiki with no formal dispute resolution process or an ArbCom. We have around 4 active admins who by policy can't determine which party is correct, act as arbiters or enforce rules without a consensus. Any help would be appreciated. Carbonaro. (talk) 03:37, 31 August 2026 (UTC)

┌─────────────────────────────────┘
I might be a bit off-topic, but I'll start with a non-technical response: don't try to solve a social problem with a technical solution. We had the same problem in Romanian regarding the old and new spelling of î/â inside articles. Note that at a certain moment in time, a single way of spelling was correct language-wise, but there was a lot of - mostly political - pushback on it. What we did was decide that both was acceptable provided that an article has a single way of writing and that once it had that single way of writing, it was forbidden to change between them unless the articles was fundamentally re-written.

Now, if you insist on a technical solution, quite a few come to mind. Tacsipacsi described a server-side solution, another is to use the transliteration engine available on srwiki. Both seem a bit overkill. A lot simpler is to use CSS as described by Nux. You can find examples for coordinates @enwiki. I suspect the same span solution could work for the interface strings.--Strainu (talk) 09:37, 1 September 2026 (UTC)

The language converter (this is the official name of what Serbian uses) is not “a bit overkill”, but a huge overkill, and uses a lot more server resources than what this social issue is worth; I find it very unlikely that operators are going to give it green light. The regional variant-based solution I subscribed is a bit less of an overkill, but (1) it would require an actual regional variant, otherwise it probably won’t be added by developers; (2) requires the use of templates (or parser functions directly), which you want to avoid.

If you want to have a solution that works without any templates (and really can’t find a social solution), I have no better idea than a gadget that tries to find these words in the article text (and hopes that it doesn’t run into a case where there are some points 2026 а., 2026 б., 2026 в. and 2026 г.).

But if you’re able to find a social solution, en:MOS:RETAIN can be a good one: whatever format the article was started with, should be used in that article. —Tacsipacsi (talk) 19:34, 1 September 2026 (UTC)

@Tacsipacsi how are multiple codes implemented on dewiki? Is there a fully-separate translation on tw.org? Would using a BCP 47 private code be acceptable and practical for the Bulgarian use-case?

@Carbonaro. I setup a quick JS based on your regex and the various gadgets around diacritics from rowiki: bg:Потребител:Strainu/common.js. It is not production ready, but it does illustrate replacement of all text elements which match your regex without the use of a template. Before wider tests, you probably need to make sure it works at scale, in both directions, that it's loaded on mobile, that the regex is good enough for all use-cases, whether you want to cover edits as well (much harder problem) etc. Strainu (talk) 22:02, 1 September 2026 (UTC)

I can’t find the code right now, but I remember having opted into the Austrian form in my preferences, so that solution definitely depends on the language being available on translatewiki.net in one way or the other (maybe the exact strings are translated on Gerrit rather than on translatewiki.net, but that doesn’t matter much – the opt-in happens through the language preference, and the language preference can be selected only if the language is available on translatewiki.net).

For the JS solution, please use the wikipage.content hook from the first moment – it’s not more difficult than using document.body, and if you forget to switch to it before going in production, the gadget is going to break when using live preview, the visual editor, the reply tool I’m just using, and probably in a number of other cases. (If anything outside of the content needs to be converted, $dateFormats mentioned above can be used for that.) —Tacsipacsi (talk) 23:11, 1 September 2026 (UTC)

Thank you everyone for your valuable input. Although the idea for a technical solution was to make everyone pleased, I understand why it proves impractical. Maybe a MOS:RETAIN policy as a middle ground will be more actionable, even though this got rejected several times due to being the most unconstructive and contrary to the spirit of Wikipedia proposal or that it would lead to the revert even of constructive edits (citing the "No article ownership" policy). I will look into Meta-Wiki RfC in the near future, but for now technical solutions may become our least priority. Thank you once again for helping me out. Carbonaro. (talk) 04:06, 2 September 2026 (UTC)