Last modified: 2014-10-04 11:33:41 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 28980 - parser tags such as <ref>, <poem>, <timeline> etc. cannot be localized
parser tags such as <ref>, <poem>, <timeline> etc. cannot be localized
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Amir E. Aharoni
: i18n
: 28977 (view as bug list)
Depends on: 71386
Blocks: rtl
  Show dependency treegraph
 
Reported: 2011-05-14 18:03 UTC by Amir E. Aharoni
Modified: 2014-10-04 11:33 UTC (History)
14 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Amir E. Aharoni 2011-05-14 18:03:21 UTC
Before the Berlin 2011 hackathon i published in several Hebrew Wikipedia-related forums a call for the most annoying RTL issues. This was the most frequent complaint:

Parser tags such as <ref>, <poem>, <timeline> etc. cannot be localized. This is not a terrible issue for left-to-right languages, but it is a serious one for RTL languages. For example, <ref> is very often used with URLs, and these get jumbled up. It's hard to write them in the first place, and it's even harder to correct them after they are written. Replacing <ref> with something like <הערה> would make adding references to RTL wikis a lot easier. The same is true for the other tags of this kind.

I talked to Victor Vasiliev and Tim Starling about it in the Berlin Hackathon 2011 and they said that it's generally doable.
Comment 1 Platonides 2011-06-21 22:25:44 UTC
<הערה> would be a nightmare to understand for foreign visitors, though :)

I think we should set a convention for having the alternate hook names in the localization file, then the extension would add the alias in addition to its canonical form.
Comment 2 p858snake 2011-06-21 22:56:16 UTC
(In reply to comment #0)
> I talked to Victor Vasiliev and Tim Starling about it in the Berlin Hackathon
> 2011 and they said that it's generally doable.
I believe its been discussed (in relation to ref at least) as doable but not really wanted to be done because of consistent use across sites so uses don't get confused and also for third party tools (eg: api access/bots to name a couple)
Comment 3 Amir E. Aharoni 2011-06-22 06:34:49 UTC
(In reply to comment #2)
> I believe its been discussed (in relation to ref at least) as doable but not
> really wanted to be done because of consistent use across sites so uses don't
> get confused

Users of the Hebrew Wikipedia get confused with the current situation. Very confused. Try editing a Hebrew Wikipedia article and think what confuses you more - the RTL-ness or the possibility that the <ref> tag would be different.

Actually, people rarely want to edit projects in languages other than their own. Those that are bold enough to edit in Hebrew will also be clever enough to understand that <ref> is <הערה>.

(I am saying "Hebrew" just because it's my home wiki; it's a drop in the bucket compared to Arabic, Farsi and Urdu.)

> third party tools (eg: api access/bots to name a couple)

They can use the same localization files.
Comment 4 Bawolff (Brian Wolff) 2011-06-22 16:55:05 UTC
I can't imagine that localizing these xml tags would be anymore confusing then how [[ملف:Example.svg]] makes an image link on ar, or using {{#لو:...}} instead of {{#if:...}}, or even the pseudo-entity &رلم; for &rlm; (These example are all from ar because it was handy).

Any bots that would be put out by this, are probably already put out by the existing localization.
Comment 6 Mark A. Hershberger 2011-06-27 14:05:32 UTC
*** Bug 28977 has been marked as a duplicate of this bug. ***
Comment 7 Mark A. Hershberger 2011-06-27 14:06:34 UTC
Maybe integrate AltTag into MW core?
Comment 8 Bawolff (Brian Wolff) 2011-06-27 18:11:51 UTC
(In reply to comment #7)
> Maybe integrate AltTag into MW core?

AltTag does a good job as an extension, but if we did this in core, we'd probably want to do something more integrated then running a regex on the wikitext before parsing imho.
Comment 9 Platonides 2011-06-27 22:01:00 UTC
Certainly not what we want for core. There will be also some cornercases such as <source><ref></source> which would fail (and AltTag regex would be a pain to review, too).
Comment 10 Mark A. Hershberger 2011-06-28 02:43:25 UTC
(In reply to comment #8)
> AltTag does a good job as an extension, but if we did this in core, we'd
> probably want to do something more integrated then running a regex on the
> wikitext before parsing imho.

(In reply to comment #9)
> Certainly not what we want for core. There will be also some cornercases such
> as <source><ref></source> which would fail (and AltTag regex would be a pain to
> review, too).

So AltTag's regex style is out.  Magic words can be localized, why not tags?
Comment 11 p858snake 2011-06-28 06:39:06 UTC
(In reply to comment #10)
> So AltTag's regex style is out.  Magic words can be localized, why not tags?
I believe they can be, but up to this point its been a undesired function so it hasn't been done in core.
Comment 12 Siebrand Mazeland 2011-09-12 12:36:21 UTC
Niklas and I discussed options. We think we must provide a solution for this. Arguments that it is confusing for users speaking other languages, or that robots and other tooling may have issues with it are less important than proper language support for users. We are of the opinion that we should implement this in regular MediaWiki messages, tagged optional, containing a comma separated list of aliases, with the English language parser tag as default value. Message keys will look like <prefix_chosen_by_developer>-<parsertag>. Assigned to Niklas.

Victor, let us know if you have something prepared already, because it's been assigned to you for four months...
Comment 13 Bawolff (Brian Wolff) 2011-09-12 18:22:59 UTC
>We are of the opinion that we should implement this
>in regular MediaWiki messages, tagged optional, containing a comma separated
>list of aliases, with the English language parser tag as default value.

This would put localized parser tag names in the hands of the users via the mediawiki namespace. This seems like a bad idea. A user could cause wide spread problems by editing such a message ( bug 23287 comes to mind. But the simple fact that changes wouldn't be immediately apparent since every page would need to be re-parsed to see if there is stuff that would now (or no longer) be a parser tag seems confusing enough to the end user to not want users to be able to change these parser tag "aliases")

I think the magic word system would make much more sense for this.
Comment 14 Niklas Laxström 2011-09-12 18:47:31 UTC
We can skip Mediawiki namespace while enjoying the other benefits of doing it that way.
Comment 15 sheac 2012-05-04 21:43:35 UTC
This bug has not been touched in at least six months. With this in mind, I've been asked by the bugmeister to bump this bug's priority down for "High". Concerns can be addressed to mah@everybody.org.
Comment 16 Dalba 2013-03-10 15:50:32 UTC
(In reply to comment #0)
> Parser tags such as <ref>, <poem>, <timeline> etc. cannot be localized.

> Replacing <ref> with something like <הערה>
> would make adding references to RTL wikis a lot easier. The same is true for
> the other tags of this kind.

If it wasn't for bug 43685, I would have suggested to use a template instead (something like {{הערה|reftext|refname|refgroup}}). A neat and painless approach I believe.
Comment 17 Amir E. Aharoni 2013-07-27 12:50:43 UTC
(In reply to comment #16)
> If it wasn't for bug 43685, I would have suggested to use a template instead
> (something like {{הערה|reftext|refname|refgroup}}). A neat and painless
> approach I believe.

Well, the Hebrew Wikipedia already uses such a template for most references, because it's just much easier to edit articles using it.

I'm coming back to this bug now for a somewhat surprising and upside-down reason: The VisualEditor. It has a nice button for inserting references, and the button, naturally, inserts <ref>. It can also edit existing footnotes only if they use <ref>.

Ideally it would be fine, because the VE is supposed to hide markup from editors, but as long as the VE is not completely stable and a lot of people continue editing in source, this will be a major problem. Localizing at least the <ref> tag can be a nice compromise.
Comment 18 Amir E. Aharoni 2014-06-11 10:19:28 UTC
Pingy.

This is being discussed in the Hebrew Wikipedia again in the same context: VisualEditor. VE inserts <ref> tags for footnotes, but the community strongly prefers a template, because using the explicit tag makes source editing hard. A bot is replacing all <ref> tags to that template. This essentially means that references cannot be edited as such by the VE in the Hebrew Wikipedia, but as templates, which makes VE editing experience confusing - an editor expects to edit a footnote, but gets a template editing dialog. Resolving this bug should make everybody happy.
Comment 19 Amir E. Aharoni 2014-10-04 11:33:25 UTC
I'd like to refocus this issue only on <ref> and little else.

In actuality, it's not impossible to have these tags localized. It's already done in LabeledSectionTransclusion. However, I don't actually think that localizing all tags to all languages is important.

In the coming age of VisualEditor localization of tags is supposed to become entirely irrelevant, because ideally they should be used only internally and not typed by editors.

Until that age comes, however, people will do a lot of manual adding, removing and editing of tags in wiki syntax mode. For tags like <poem> and <timeline> it's not actually disastrous and nobody really complains about them (the content of <timeline> is a pain in RTL, but that's an entirely different issue).

For <ref> however, it's a nightmare in RTL languages. What I am imagining at this point is a way to get <ref> localized to RTL languages (and probably not even all of them) using a mechanism that is works with wiki syntax and with VisualEditor and Parsoid, and to be ready to get rid of it in the far future when direct wiki syntax editing becomes unimportant.

I committed an experimental patch for this:
https://gerrit.wikimedia.org/r/#/c/163467/

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links