Re: Appeal to devs: please be considerate on translator time

Dreamy Jazz <[email protected]>
Newsgroups gmane.science.linguistics.wikipedia.technical
Message-ID <CAG7AY3DYTgvkb=S+uCccznYkn07RdC4zv=ZmnjW2z0jhSJ0zDQ@mail.gmail.com>
Hi,

I'll answer your side question. The "#special" syntax is used to represent
the translated name of the special page in the message while avoiding the
need for a translator to copy this to the message.

Thanks,

Dreamy Jazz


On Tue, 13 Jan 2026 at 14:14, Strainu <[email protected]> wrote:

> Hi all,
>
> *Disclaimer*: I'm writing this mail with my translator hat on. Throughout
> this email I will give some examples encountered in today's translation
> session to clarify my arguments. If you wrote the code that contain those
> strings, please don't take this personally - it's a community problem, not
> a personal one.  This is why I'm not providing the exact message names, but
> only the strings.
>
> I've been translating OSS for 25+ years and MediaWiki for almost 20 years.
> For me, It has always been a common effort: the devs need to extract the
> strings, document them to give context and export them to the proper
> tooling, while translators need to understand the product, fill the
> (context) gaps and be consistent.
>
> With our 284 languages and hundreds of thousands of strings, we're
> definitely on the high side of effort needed for translations. However, in
> the last few years (I would say, roughly from Covid) I see more and more
> cases when the* effort is moved toward the translators*.
>
> It used to be that commons strings like Yes/No, Log in/Log out
> Watch/Unwatch, Edit or Save were only present once per module. Today? "Log
> in" (with this exact casing and no combinations) is present at least 5
> times in  MediaWiki core - User interface. Yes and No - 3 times each.
> Name - 4 times and the list on.
>
> Another type of duplication are messages 90%+ alike, such as "Talk pages
> for pages in the main/MediaWiki/.template namespace" instead of "Talk
> pages for pages in the $1 namespace". I found at least 3 such instances,
> there might be more.
>
> But wait, there is more. Strings like " [[{{#special:Contributions
> }}/$1|$2]] ([[{{ns:user_talk}}:$1|talk]]) " should not exist at all.
> First, there is absolutely no guidance on what parts should be translated.
> [1] I would guess only "talk", which should be replaced with reusing the
> simple message (aka {{int:talk}}), so nothing to translate. This would save
> the translators the significant amount of time needed to decode the
> message, make assumptions and (not) translate the text.  I have some more
> examples, but I'll stop here.
>
> We must not forget that the translators are also members of our community
> and the translation time wasted on such strings could be better used doing
> other activities in the Wikimedia world. The benefits are not small: 1s
> saved over 284 languages means almost 5 minutes. If fixing your string
> takes 15 min or less, it's probably worth it.
>
> I therefore encourage developers, project and people managers to* review
> their practices* on generating strings and reviewing code in order to *reduce
> the number of spurious messages* that the translators need to work on.
>
> Have a great year ahead and may you code be bug-free!
>   Strainu
>
> [1] As a side question, I'm very curious about the "#special " syntax -
> who's expanding that into a proper namespace?
> _______________________________________________
> Wikitech-l mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

_______________________________________________
Wikitech-l mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.