Last modified: 2013-07-29 15:20:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T45380, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 43380 - Bring settings translations on mediawiki.org: dummy install of Configure extension
Bring settings translations on mediawiki.org: dummy install of Configure exte...
Status: NEW
Product: Wikimedia
Classification: Unclassified
Extension setup (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
https://www.mediawiki.org/wiki/Thread...
: i18n
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-24 11:23 UTC by Nemo
Modified: 2013-07-29 15:20 UTC (History)
7 users (show)

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


Attachments

Description Nemo 2012-12-24 11:23:52 UTC
Configuration settings are the most translated kind of pages on mediawiki.org, but the translations are still very few.
On the other hand, the Configure extension duplicates all the settings' summaries and has over 23 thousands translations for them.

I'm opening the bug to see what's technically feasible. The discussion on how to manage those pages should continue on the wiki, see URL; for now the reactions seem to be that it's ok to make them translatable in whatever way works and as long as someone else does it. ;-)

Matma Rex is doing lots of updates to the extension (method still to be figured out exactly, see I14f5815a) and many translations may need to updated, but it's a pity to waste those translations and it's a nightmare to copy them around.
Is it possible to do a dummy install of the extension on mediawiki.org just to use its messages? Like, $wgConfigureEditableSettings with a single dummy config, the special pages unset and the required permissions assigned to no group.
Comment 1 Waldir 2013-02-15 03:04:53 UTC
By default, the rights "configure", "configure-all" and "extensions" are given to bureaucrats. We can simply install the extension, then override those settings with 

$wgGroupPermissions['bureaucrat']['configure'] = false;
$wgGroupPermissions['bureaucrat']['configure-all'] = false;
$wgGroupPermissions['bureaucrat']['extensions'] = false;

and then no harm can come from it. (Special:ViewConfig will still be available for sysops)

But the fact that this extension doesn't handle ALL configuration settings makes me think we might need a more robust solution. Would it make sense to have a DefaultSettings.i18n.php file?

On the other hand, the unsupported configuration settings are just a handful: [[mw:Extension:Configure#Special:Configure]]. Maybe the extension's i18n file can include those just for completeness.

Which of these choices would be preferable?
Comment 2 Nemo 2013-02-15 06:39:48 UTC
(In reply to comment #1)
> Which of these choices would be preferable?

I think that it doesn't matter and should be a separate bug against the extension. If the community agrees on the fact that it's useful to have the possibility to use such messages on wiki and no technical obstacle is found to enabling it "read only", such imperfections can be sorted out later/independently.
In the discussion on wiki nobody opposed; this bug has not yet had comments on security problems or better alternatives or lack thereof, maybe the devs who didn't like the idea much at first will find out that there's no reason not to do it.
Comment 3 Waldir 2013-02-15 17:27:51 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Which of these choices would be preferable?
> 
> I think that it doesn't matter and should be a separate bug against the
> extension. If the community agrees on the fact that it's useful to have the
> possibility to use such messages on wiki and no technical obstacle is found
> to enabling it "read only", such imperfections can be sorted out
> later/independently.
Agreed, let's focus the discussion on getting the extension deployed.

> maybe the devs who didn't like the idea much at first will find out
> that there's no reason not to do it.
Who are the devs who didn't like the idea? Maybe we should poke them towards commenting on this bug.

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


Navigation
Links