Page MenuHomePhabricator

messages like MediaWiki:Babel/am could be wrongly rendered due to Amharic full stop (can be misread as "double colon" in sometimes)
Closed, ResolvedPublic


Incorrect wikilink displayed in Babel box for the link going to "Category:User am-N" : a <del>space</del><ins>double vertical bar</ins> is used where there should be a single vertical bar separator


reopen because this translation is NOT on itself!

Event Timeline

Note: the bug is in the internal i18n JSON datatables used by the Babel extension (in PHP)

Aklapper changed the task status from Open to Stalled.Feb 13 2018, 1:03 PM

I do not see any link in . Hence unclear what this is about and where is the "i18n issue".
Please follow and provide 1) steps to reproduce the problem, 2) expected outcome, 3) actual outcome, in separate sections.

The bug is here (line 14):

actually there is two vertical bars instead of just one, I thought there was a space, but here the double vertical bar creates a column separator in the rendered wikitable.

The bug is visible when just displaying a Babel box with "am-N"

Example: look at the "Portal:am" page in TranslateWiki:

It was initially reported here:

Verdy_p triaged this task as Medium priority.Feb 13 2018, 1:11 PM
Verdy_p updated the task description. (Show Details)
Verdy_p updated the task description. (Show Details)
Verdy_p updated the task description. (Show Details)
Aklapper removed a project: I18n.

This needs to be fixed on (and can be discussed on the corresponding talk page or support page), hence closing as invalid.
Also removing I18n as there is no general internationalization issue in the software but a typo in one specific translation / language.

It is valid because there's NO resource to translate in the Babel project on for these strings.
Yes it is specific to that single language (am), and that's what was in the initial report.
So reopen please, and check the format of your *i18n* JSON data which does not come from translations itself (there's no project for these strings, only for some generic strings of the Babel box).

Even if we define [[Mediawiki:Babel-N-n/am]] correctly, this resource is NOT transcluded because the Babel extension first looks into its i18n JSON tables, and if it finds the resource there, it uses it directly. It is not overriden by trying to transclude [[Mediawiki:Babel-N-n/am]] which is generally NOT imported on wikis using the Babel extensions (they don't import any [[Mediawiki:Babel-LEVEL-n/LANG]] pages), they just install the extension with its i18n JSON datatables.

So yes the report here is valid: it cannot be solved in itself ( where these strings are not listed there (only 6 generic strings) but only in the 18n datatable for now (that cannot be synchronized with what comes from translations in

@Aklapper: users are constantly redirected from one supprot page to another, rejecting the fault to someone else or another proejct, this is very irritating. There's no clean way to discuss such issues and no central place. Before I was sent somewhere else and it was denied too. The relevant discussion page is not followed (it was reported in the page I gave above as reference which seemed appropriate).

I gave proof of this bug, a link showing the demo, I located the fault in the JSON data (which is the effective place where the broken string is present, and which is not synchronized with what is in, given these strings have been removed from the Babel extension. We can find them in Translate wiki only in old archived translations that have been dropped from the module and no longer offered to users to translate, because they are no longer "needed", being part of the i18n JSON data of the extension which is installed only with these and now not requiring any import of thousands of Mediawiki:Babel-LEVEL/LANG pages on all wikis and not requiring any transclusion to render the Babelbox)...

Verdy_p updated the task description. (Show Details)

I don't think there's JSON errors existing, if those exist, then non of will not be affected.

Since it looks like only that Amharic message is broken, I wonder if this is the real problem that made such rendering error: In Amharic, users usually translate the U+002E full stop "." to "።" (U+1362 Ethiopic full stop), but kindly OK, this task should be reopen, as there's really existing a bug in MediaWiki-extensions-Babel that misread that Ethiopic full stop as "double colon", which therefore break the category link

Can we check/lint these kind of errors in Babel resources ?

  • May be just grepping for '||' or '::' would find format problems (Translatewiki already checks unpaired brackets/parentheses).
  • There may be other errors such as unpaired HTML tags (e.g. sub/sup, which may be needed for some translations), not just for Babel but for other subprojects as well, or HTML tags paired incorrectly (<x>...<y>....</x>...</y>) which cause various problems (even in HTML5 if this occurs with block elements)

Can we develop other linting rules for Translatewiki to help diagnose such problems by making these resources fuzzy and avoiding importing them automatically in projects?

May be closed now, the bug is solved for this string, but may a a TODO task can be made to check similar problems and prevent them to occur later at any time in any language (double vertical bars should not exist within square brackets).

Note that in Wikisyntax, the parser does allow a table cell to contain unpaired braces or brackets: they are then kept as if they were plain-text so the syntax:

| [sometext1 || othertext1]
| [[sometext2
| othertext2]]

is a "valid" 2x2 wikitable, but do not generate any links. Translatewiki detects unpaired braces or brackets, but does not detect double vertical bars (||), or double exclamation marks (!!) which could cause problems everywhere the translated resource is used in the cell of a wikitable. Even a single exclamation mark or vertical bar at start or end of a resource could cause problems if the translated resource is used immediately at start of a table cell without attributes or at end of any cell (if there's another cell starting immediatetly on the same source line).

Developers should then take care about how they build wikitables containg translatable resources ! If the project asks to translate contents intended to be used via the MediaWiki parser, these translatable resources should never need to use any exclamation mark or vertical line, or only within paired brackets/braces, and never two exclamation marks or two vertical lines between square brackets).

All these are caveats of the ambiguous MediaWiki syntax and an undesired effect of its "tolerance". They cause problems each time we transclude things which isolatedly seem valid but won't work as intended in their context of reuse.

For this reason, translation admins should avoid submitting projects to translate with them:

  • never ask to translate more than a single paragraph or single table cell
  • never depend on Mediawiki quirks
  • preferably use plain HTML tags in translation units for inline contents only.
  • hide tricky HTML syntax (or transclusions of templates) within $placeholders (or tvars with the Translate extension of MediaWiki).
  • placeholders should have no parameters at all (e.g. "%12.5d") only indicators for identifying placeholders in the translated string (e.g. "$2", or even better "${varname}" or "%2%" with explicit closures, are always better as placeholders than "%2!s" in a translation unit for C/C++ format strings), otherwise you'll have problems with some languages, notably Asian languages without space separators, or languages using punctuation differently or needing specific punctuation, and different ordering of statements.
Aklapper raised the priority of this task from Medium to Needs Triage.Jun 20 2018, 7:35 PM

@Nikerabbit Oppose, the issue that about "።" (Ethiopic full stop) still exists in the MediaWiki core codebases (some messages and scripts still misread that as "double colons"), although not sure if still exists on Babel extension

Liuxinyu970226 renamed this task from [[MediaWiki:Babel/am]] i18n issue to messages like MediaWiki:Babel/am could be wrongly rendered due to Amharic full stop (can be misread as "double colon" in sometimes).Mar 22 2019, 2:35 AM
Nikerabbit claimed this task.
Nikerabbit added a subscriber: Liuxinyu970226.

@Liuxinyu970226 I'm closing this bug. If you can provide evidence of what you claim, then please open a new bug with steps to reproduce, since this task as originally filed was resolved.