Jump to navigation Jump to search
NoteProblems? Questions? Suggestions? Write your message below. — See also the FAQ or try to catch us in IRC.

Your request has been forgotten? Feel free to post a reply to bump the thread to the top. Very old threads have been archived.
(The thread summarization feature is broken, see: Phab:T245109)

First page
First page
Last page
Last page

Translation updates on home wiki

Hi, I read the FAQ, but I still have few questions regarding the translation updates on home wiki

  1. Is there a place where I can see when was the last time when translations are applied/updated on a local wiki (+ is there a specific period and more details about these updates) (Bulgarian Wikipedia)
  2. We have a case with translation updated at 31 October 2018 which is not yet applied to our Wikipedia (and is not overriden via a system message): [1]. How's that possible?
  3. Is there a way a contributor to force translations update on a home wiki (Bulgarian Wikipedia) or to set these to be done in shorter period
StanProg (talk)09:24, 14 August 2019

Now I'm thinking, could the reason for this be that these messages are not marked as "reviewed"?

StanProg (talk)08:55, 15 August 2019

1) Currently translation updates go with the MediaWiki train:

2) That message is no longer used by the software, so it is not updated.

3) No, but we are hoping to get back to daily updates in the next 12 months.

Nike (talk)08:58, 15 August 2019

Get really "unreviewed" messages only

Hi, when proofreading messages and selecting the "Unreviewed" filter I am presented with many messages that have already been reviewed by one or more people. Looking at the URL I get when clicking that filter (!reviewer%3A1314%7C!last-translator%3A1314&setlang=en&language=de) it seems that the software's notion of "unreviewed" is "all messages that the current user has not reviewed or created/edited". So this means to clear the backlog I need to review ~18k messages for the MediaWiki namespace only, not to mention the other projects. The idea of translatewiki is that the effort is distributed among several people, i.e. I do not want to do the work that someone else has already done and review stuff that has already been reviewed by many people. Is there some way I can view the really unreviewed messages, i.e. the messages that have not been reviewed or maybe not by more than 1 or 2 people? Thanks and regards,

ChrisiPK (talk)01:01, 24 May 2014

As explained in mw:Help:Extension:Translate/Quality_assurance, the feature is certainly not thought for blocks of 18 thousands messages: the current process to do what you describe is to review one group and then mark it proofread (a feature active on Meta for instance).

1, 2, 3 or 100 reviews: when is a translation "reviewed enough"? That's not a judgement that Translate currently does. Do you have a proposal on how to add an option to filter translations reviewed by N others without cluttering the interface?

Nemo (talk)08:54, 24 May 2014

From looking at the URL the extensions seems to have quite an extensive filtering system (given the complicated filter expression). I don't know how sophisticated this really is but I would hope that it would be possible to create an expression that gets those messages I am looking for. I would recommend an additional tab "Custom" that will then present me with an interface where I can create my own filter expression. Also I think we should change the "Unreviewed" tab to actually show messages that have not been reviewed by anyone. This makes the behavior consistent with the Untranslated tab: It shows all messages which have not been translated by anyone, not all messages which have not been translated by me. Regards,

ChrisiPK (talk)10:32, 24 May 2014

Hi, I have the same problem as ChrisiPK: when I have to review translations, I would prefer to review only those that have not been reviewed yet. To me the most sensible thing to do would be to sort messages in "Unreviewed" tab by the number of times that they have been reviewed, in ascending order, i.e., first unreviewed translations, then translations reviewed once, then twice, etc.

A3nm (talk)14:39, 8 August 2019

Please try this workaround. When you access the unreviewed translations, you will find in the URL of the page the following string reviewer%3A followed by some number. Delete this number and the %3A that precedes it. Possibly some browsers will show = instead, but it means the same thing.

Nike (talk)15:59, 12 August 2019

Created this new feature request -

Abijeet Patro (talk)16:58, 13 August 2019

FuzzyBot copy-pasting English lines to Danish

// WikiPhoenix Talk19:05, 9 August 2019
Shirayuki (talk)07:21, 12 August 2019

Reported in

Unfortunately, since these already got exported, there is no simple way to fix this automatically, as I just can't simply delete those bad translations.

Nike (talk)08:21, 12 August 2019

I've reported to avoid this happening in the future.

Nike (talk)16:03, 12 August 2019

What exactly is being deleted here? Some unfortunate languages has genders for stuff that English does not have.

Stoyan (talk)19:17, 30 July 2019

A map object (a node, way or relation).

TomH (talk)19:26, 31 July 2019

What exactly is being closeed here? Some unfortunate languages has genders for stuff that English does not have.

Stoyan (talk)19:17, 30 July 2019

Have opened an issue on their issue tracker -

Please look for a response either here, or there.


Abijeet Patro (talk)18:48, 31 July 2019

A changeset (a group of changes to the map).

TomH (talk)19:25, 31 July 2019

What exactly is being closed here? Some unfortunate languages has genders for stuff that English does not have.

Stoyan (talk)19:16, 30 July 2019

A changeset (a group of changes to the map).

TomH (talk)19:25, 31 July 2019

What exactly is being created here? Some unfortunate languages has genders for stuff that English does not have.

Stoyan (talk)19:16, 30 July 2019

A changeset (a group of changes to the map).

TomH (talk)19:24, 31 July 2019

Hi, how I can translate this? I don't know how is Czech "nepřečteno" in IPA.

Patriccck (talk)18:47, 29 July 2019

username change

Hi, can I request a username change to Paradox, please? Thank you.

Onubadok (talk)07:18, 25 July 2019


Amir E. Aharoni (talk)11:07, 29 July 2019

Thanks a lot.

Paradox (talk)14:42, 29 July 2019

Add Eastern Balochi Language to Translator

Hi, I have request to Add Eastern Balochi on Translator with native name toسلئیمانی(بلۏچی) This Language ISO-609-2 Code is bgp S I E Z A/SK7 09:07, 28 July 2019 (UTC)

S I E Z A/SK709:07, 28 July 2019

Change Southern Balochi Native Name

Hi to Adminstratin I am one of Balochi Academy Sarbaz Admins We have been working on Balochi Language that oue most work on Southern Balochi. We want to Change Southern Balochi(bcc) native name to کݔچی(بلۏچی) thank you.

S I E Z A/SK7 09:04, 28 July 2019 (UTC)

S I E Z A/SK709:04, 28 July 2019

Is Hive.js deprecated?

Hi folks, it looks like Hive.js has been retired as a project. The domain is dormant and the source code repository hasn't received an update in months. It may be advisable to mark it as such on as you have with previous projects here that are now (sadly!) defunct.

Yannis A |23:42, 19 July 2019

You are right. Worse, the domain was squatted.

Nemo (talk)08:42, 20 July 2019

Relatedly I filed a while ago.

I reached out to the contact person and they confirmed that it is now defunct.

Nike (talk)20:13, 20 July 2019

I have dropped hivejs from translation, and noted this in News.

TODO: Someone should update the project page and associated user templates.

Nike (talk)10:31, 21 July 2019

Done. Updated the project page, and the associated user template.

Niklas has also documented on what needs to be done as part of the project deprecation process -

Abijeet Patro (talk)03:26, 25 July 2019

URL should be capitalized in this message.

Siebrand08:04, 17 July 2019

Submitted a ticket on Phab -


Abijeet Patro (talk)03:23, 25 July 2019

Template:Disabled language

Wondering whether I could get a second opinion at Template talk:Disabled language. I feel like the warning given by that template is unnecessarily vague and could be improved with a little more information (additional text) and/or a few choice links (or maybe just a retargeting of the existing link??). Alternatively, the template could be split into different ones based on the underlying reasons for tagging. Note that I am not a translator here for any language, so perhaps those who are (or who are in the process of becoming one) would have a different experience. I just feel like the catch-all nature of the warning given by that template leaves readers with no useful clues as to why the page has been so tagged. (For example, Portal:tlh, Portal:chb and Portal:szy have all been tagged, but presumably for very different reasons. [I assume Klingon will never be enabled here, but surely that cannot be true of the other two.]) Note, BTW, that the template is used on both portal and category pages. Not surprisingly, the creator and sole editor of the template sees nothing wrong with it. Perhaps others will disagree.

dcljr (talk)23:31, 17 July 2019

I just took existing sentences I found on some pages. But the only link found was to the page currently indicated. If you want to suggest other links, please do so.

I can only suggest for now adding a "reason=*" to the template for a freeform text (that will not be translated by the template), including the possibility to integrate a wikilink to some decision page describing the issues.

Also you affirmed (in a prior talk) that the message was only in English, and this is wrong: it's shown in over 60 languages, plus some known fallbacks from other regional languages or from variants that are user selectable in the Universal Language Selector. The text in all of them is the same, based on the same English source.

Also I suggested you to fix possible typos or imprecision that may exist in some translations. But before adding things in a specific language, make sure that the English base is in sync wit the proposed additions.

All I did was to mark explicitly the languages that are NOT selectable in the Translation tool (following any link using these language codes will not work, because the translation tool will immediatzly switch to another unrelated language (based on the current user's UI language and not at all on the indicated target language), and new translators may not notice it (there's no notification on the screen, the only thing being indicated is the name of the effectively selected language in the top-right corner) and they could start overwriting valid translations for that unrelated language by translations in a disabled language. This was the main reason for which I made these indications explicit.

Verdy p (talk)00:14, 18 July 2019

Klingon probably won't be enabled, and this was discussed many times.

Sakizaya will probably be enabled. It's a technical matter now. The best place for discussing it is

As for Chibcha, it's the first time I'm hearing about it, but it is unlikely to be enabled given what the Wikipedia article about it says (extinct circa 1800). I'm flexible about sincere and serious language revitalization projects. I'm not quite sure why was it ever added to translatewiki.

The Sakizaya case is the most confusing here, of course. The template on the portal looks very fatal, and it's not quite the case. It should be rephrased for clarity, probably with something like a "status" or "reason" parameter.

Also, its translations should really be moved to a proper localization system, like or something ;)

Amir E. Aharoni (talk)10:00, 23 July 2019

"Its translation should be moved to ...".... We are on ! is not required to support only Wikimedia projects, it can support Wikia, where Klingon is accepted (but it uses a script that is not encoded in Unicode, only encoded in ISO 15924. The proposal to encode the Klingon script was made by Michael Everson at Unicode, and as it was rejected, Klingon is for now encoded in PUA space using the "ConScript PUA registry"... managed by Michael Everson which supports more languages than what ISO/IEC WG2 or the UTC want to support.

It was rejected simply on the fact that most Klingon users wrote it in the Latin script (but with several variants or transliterations, not always the one promoted by KLI, notably some users prefer using extended latin which more accurately represent the sounds, like c with hacek, small capital i, or l barred with curl, and then allow the script to be romanized with common dual casing, which makes it more readable).

There's nothing wrong in translating MediaWiki in Klingon even if there's no Wikimedia project for it. But Wikimedia wiki do not want to support languages written in scripts requiring the use of PUAs (nomally intended to be for private use, and then limited in scope to specific projects using it in their own community).

Also I'm not adding any new language, I'm just sorting what is existing on this wiki, and then display a correct status.

Verdy p (talk)10:10, 23 July 2019

In January 2019, SIL gave Sakizaya the language code "szy", as noted at m:Requests for new languages/Wikipedia Sakizaya#January 2019 update. Shortly afterwards, I created Portal:szy here because I thought that would be helpful. However, the language was already being translated here under the code "ais". In the meantime, incubator:Wp/ais was moved to incubator:Wp/szy. I posted about this at Thread:Portal talk:Ais/Should be at Portal:Szy, but I guess "no one noticed". Yesterday, Portal:szy was tagged with {{Disabled language}}, apparently because it had no active translators (they are listed at Portal:Ais).

So, now I am "formally requesting" that everything on this wiki currently under "ais" be moved to "szy". (I'm not sure what all is involved in doing that.)

(Note that I do not know the language; I'm just interested in seeing everything get "in sync" after the designation of the "szy" code. Pinging @StevenJ81 and Liuxinyu970226: as they may have further information and/or an opinion they want to express about this change.)

dcljr (talk)00:59, 17 July 2019
Edited by author.
Last edit: 00:09, 19 July 2019

Note that some stuff under "szy" (Sakizaya) may actually belong under "ami" (Amis), as discussed at m:Requests for new languages/Wikipedia Sakizaya#January 2019 update. I guess this complicates the issue and means that things cannot simply be moved wholesale, as I suggested. But "ais" has been deprecated, so clearly something needs to be done here. I will leave it to others to determine what that is.

Note that we currently have no translators listed at Portal:szy and that language has not been enabled for translation, but at least one of the translators listed at Portal:ais appears to be among the users asking for a Sakizaya Wikipedia, so maybe they can help? (I've notified a few such users about this thread.)

Also note phab:T174601, which is discussing the same issue from a different perspective (Wikimedia wiki configuration).

Edit: As pointed out by StevenJ81 below, I actually meant to say: "Note that some stuff under 'ais'… may actually belong under 'ami'". Sorry for any confusion this may have caused.

dcljr (talk)01:39, 18 July 2019

Hi @Dcljr: I'm sure there are no stuff or content under "szy" belong under "ami". So how can we do to move all translations listed at Portal:ais to Portal:szy? We thought it would be moved just like the case with incubator:Wp/ais to incubator:Wp/szy. @Amire80: @StevenJ81: Is it possible to fix this problem? If negative, should we improve the portal one by one manually? Corainn (talk) 08:37, 18 July 2019 (UTC)

Corainn (talk)08:37, 18 July 2019

Look, it just sometimes takes time to sort some of these things out. I wouldn't worry a lot. @Corainn, if you are quite sure that nothing currently within language ais is actually Amis, then we could outright move everything from ais to szy. Otherwise, the thing to do is to copy everything from ais to szy, and worry about the disposition of ais later.

@Amire80, I can assure you that (a) szy is appropriate for Sakizaya, (b) pretty much everything that had been put previously into ais is really Sakizaya (I'll find the rather robust discussion history if you like), and (c) ais for "Nataoran" has been deprecated in favor of including Nataoran within the rest of Amis (ami). So please help us move this along. Thanks.

StevenJ81 (talk)13:49, 18 July 2019

@StevenJ81: Great to hear that and thanks for the reply! Yes, there are no overlaps between amis and szy(ais), I‘m very sure. If something could be done by our side, please let me know.

Corainn (talk)22:02, 18 July 2019

@Amire80 is working on this at Phabricator now. See phab:T174601.

StevenJ81 (talk)14:03, 22 July 2019

New language request for Min Bei Chinese (mnp).

Please add support for the Min Bei Chinese language.

Language name Language code Native language name
Min Bei Chinese mnp Mâing-bă̤-ngṳ̌/閩北語

Please add this language to Special:SupportedLanguages.

Please add Portal:Mnp to Category:Languages, and please let the first line of the page Portal:Mnp show correctly, like this:

mnp: Min Bei Chinese, Mâing-bă̤-ngṳ̌/閩北語


Also, in incubator, please let the babel box of Category:Users:By_language:mnp display correctly.

Yejianfei (talk)12:39, 14 February 2019

What is the *prefered* Han variant: Hans or Hant ? Check the portal to make sure they are ordered by preference.

Note: the "disabled" status in the portal reflects the current state (to avoid linking to a non-open translation tool), it's not meant to block the activation of the language, if the site administrator accepts it. Just Removing the "disabled" state will still not activate the language in the translation tool.

But please specify which Han variant you intend to support (it cannot be guessed from the current Wikipedia Incubator that currently uses Latin viaibly preferably to Latin, then uses an unspecified Han variant, possibly both are mixed there).

For questions related to Babelboxes in the Incubator, this site is not the place to go, because Babelbox messages are translated inside Mediawiki itself: contact the Incubator admins to see what they can do for you.

Verdy p (talk)10:43, 22 July 2019

"$2 edits to Articles for deletion pages" Is it "[Articles for deletion] pages" or "Articles for [deletion pages]"?

Urhixidur (talk)11:12, 14 July 2019

Hello Urhixidur,

I spoke to Niklas, and we are confident that its the first one but have opened a support ticket to clarify it further.


Abijeet Patro (talk)09:03, 15 July 2019

Hi Urhixidur,

Please see the response here -

Abijeet Patro (talk)09:46, 22 July 2019

Please delete MediaWiki:Centralauth-logout-progress/ka is obviously not Georgian but English. Could someone please delete that page?

AKlapper (talk)18:06, 6 July 2019



Abijeet Patro (talk)11:10, 7 July 2019

Couldn't you just provide the actual Georgian translation instead of deleting (which will still have the effect to display the message in another fallback language, may be in Russian on some wikis that have such fallback, but most often in English ! There's nothing wrong in fact if there are some messages untranslated still in English (or partly in English). On (or other wikis using the translate extension), this is sometimes a transitory step, just allowing to initialize a set of pages with working links, before the whole set gets translated, without breaking things.

If you detect an English message that you want others to translate, the best thing to do is to just insert a "!!FUZZY!!" prefix before it, so that the message remains marked as needing an actual translation. You never need to delete that page, and this preserves its history.

I am convinced that this "!!FUZZY!!" prefix should be autodetected by the Translate tool, not even being displayed in the editable form when it is at start of a message, but replaced by a "yellow notification" displayed at top, and by a checkbox "mark this message as fuzzy" near the Save button. Internally the page will contain the edited message (even partly translated) but the "!!FUZZY!!" prefix will still be there: you can still continue editing it (in several steps), but as long as you don't uncheck that checkbox, saving it will still not change that status and it will be impossible to "validate" that message. A validator however can look at "!!FUZZY!!" messages and accept its content without having to do any editing, he will just unckeck that box and save again.

Verdy p (talk)15:19, 9 July 2019

@Verdy p: feel free to just become part of the Georgian translation team and to just provide the translation. There is nothing wrong if there are some messages untranslated and nothing every challenged that so nobody knows why you bring that up even. For random FUZZY discussions please use a discussion forum.

AKlapper (talk)12:15, 17 July 2019

@AKlapper: I know I can do that, but for this topic I cannot help. My reply was general. There are some reasons why resources get marked as fuzzy, and there's also a way to mark an existing translation as being fuzzy again, without deleting it completely (which is bad as it cancels all its history), when it is still actually requested and a fuzzy translation may still have contents whose translation is still unclear (frequently this is because the source message is ambiguous, and lacks documentation about its usage, e.g. missing clear distinction between isolated verbs and nouns in English, or multiple meanings of the same orthographic term). Another reason is that most of the message was considered OK, but there's an issue in the existing translation caused by an update in the source message. Making some resources fuzzy is enough to solve those issues without deleting them. Another viable reason is that a single resource for a translatable page is marked fuzzy (only copying the English source) in order to force the translation tool to create the first version of the target page (which has incoming links to it): even if the whole page is still not translated, it is still best that it displays the English fallback content, even if the whole page remains to be translated. Finally another reason is that it also allows importing resources from an older translated page (but whose translation was manual, still present in its history, and its existing content will be manually parsed to import and convert it to the translate tool. So the "fuzzy" mark is an intermediary step before looking for other existing pages to find the terminology previously adopted. It's a useful feature, even for actual translators.

Verdy p (talk)16:58, 17 July 2019

Hi Verdy,

Thanks for your inputs. I'll keep this in mind for future.

If the translation has already been exported, deleting it will not help, so in such cases marking them as fuzzy is probably a better idea.


Abijeet Patro (talk)17:59, 17 July 2019

Parameters should be documented and be insertables.

Siebrand08:02, 17 July 2019
First page
First page
Last page
Last page