[go: up one dir, main page]

Page MenuHomePhabricator

Figure out Wikimedia wikis' Special:Contributions footer (duplicative and difficult to maintain)
Open, LowPublic

Description

TLDR: We currently have hundreds of local variants, each of which have to be created, and translated, and then maintained, separately. (e.g. 18 translations at mediawikiwiki, and 4 translations at metawiki)

I think we should be putting all the best tool links into Extension:WikimediaMessages and translating it at translatewiki.

The goal is to minimize translation requirements, minimize maintenance efforts when a URL changes, and to get links to the best tools into the hands of all editors in all Wikimedia wikis.


Details: (Split out from T24516 comment 14 by @Quiddity)

I believe (part of) the original intent of [that] bug is to rethink/standardize/centralize the items in [[MediaWiki:Sp-contributions-footer]]. E.g.

Plus the "-anon" variants at all ~900 wikis, eg c:MediaWiki:Sp-contributions-footer-anon )

Because the individual links at various wikis are frequently:

  • broken/outdated
  • or missing
  • or in an inconsistent order
  • or in a language we can't read.
  • Plus, the entire section is completely missing, if we have our language-preference set to a non-local-default, and that language-variant has not been manually created locally. (try looking at this usercontribs page with your UI language set to anything other than French.)

Suggested action item:


@MZMcBride writes:
This enhancement request might ultimately be a ticket against MediaWiki extensions --> WikimediaMessages, but this needs further thought and consideration first. I think a clear problem has been identified (footers that are duplicative and difficult to maintain), I'm just not sure what the best path forward is yet. There are other options such as interwiki transclusion (hah). We need to develop a plan.

Details

Reference
bz65446

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:20 AM
bzimport set Reference to bz65446.
bzimport added a subscriber: Unknown Object (MLST).

I've overhauled the description above by reformatting it, and adding this major detail:

  • Plus, the entire section is completely missing, if we have our language-preference set to a non-local-default, and that language-variant has not been manually created locally. (try looking at this usercontribs page with your UI language set to anything other than French.)

I also re-read this comment on the related task, which might be the solution we need? (Slightly beyond my tech level, plus I'm tired, so am not sure.)

Another option may be to add another message that's the same in all languages (aka $wgForceUIMsgAsContentMsg) and display it below the default message. Just like recentchangestext or the edit tools.

TLDR: We currently have hundreds of local variants, each of which have to be created, and translated, and then maintained, separately. (e.g. 18 translations at mediawikiwiki, and 4 translations at metawiki)

I think we should be putting all the best tool links into Extension:WikimediaMessages
and translating it at translatewiki.

The goal is to minimize translation requirements, minimize maintenance efforts, and to get links to the best tools into the hands of all editors in all Wikimedia wikis.

@MZMcBride wrote:

This enhancement request might ultimately be a ticket against MediaWiki extensions --> WikimediaMessages, but this needs further thought and consideration first. I think a clear problem has been identified (footers that are duplicative and difficult to maintain), I'm just not sure what the best path forward is yet. There are other options such as interwiki transclusion (hah). We need to develop a plan.

Are there any drawbacks to creating this string in Extension:WikimediaMessages and doing the translation at translatewiki?
The only major one I can think of, is individual wiki-communities who are accustomed to their unique ordering & selection of the links, being confused by a re-ordering (standardization). And thus we'd need to some research and feedback-requests and announcements.

Are there any other practical options?