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

The bug is here (line 14):
https://phabricator.wikimedia.org/diffusion/EBAB/browse/master/i18n/am.json

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:

https://translatewiki.net/wiki/Portal:Am

It was initially reported here:

https://translatewiki.net/wiki/Portal_talk:Am

Not sure if my https://translatewiki.net/w/i.php?title=MediaWiki%3ABabel-N%2Fam&type=revision&diff=7890816&oldid=6350052 works or not? Since I don't know why this user used double |

It is valid because there's NO resource to translate in the Babel project on Translatewiki.net 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 Translatewiki.net 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 Translatewiki.net itself (https://translatewiki.net/wiki/Special:Translate/ext-babel?group=ext-0-all&language=fr&filter=&action=translate) 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 Translatewiki.net)

@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 Translatewiki.net, 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)...

I don't think there's JSON errors existing, if those exist, then non of https://phabricator.wikimedia.org/diffusion/EBAB/browse/master/i18n/ 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.

@Verdy_p So you want translatewiki.net to convert its contents from Tidy to RemexHtml?

https://codesearch.wmflabs.org/search/?q=%3A%3A&i=nope&files=json&repos=Extension:Babel
https://codesearch.wmflabs.org/search/?q=%5C%7C%5C%7C&i=nope&files=json&repos=Extension:Babel

There are no similar errors in Babel. As far as I can see there is nothing more to do.

@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