Page MenuHomePhabricator

The message 'copyright' should be an interface message, not a content message
Closed, DeclinedPublic

Description

Author: alefzet

Description:
In all multi-variant wikis (eg sr.wikipedia.org, sr.wiktionary.org etc) content of 'copyright' key
(displayed on bottom of mainpage) does not switch to language variants.
See for example sr.wikipedia.org: the text "Ваши доприноси се објављују под ГНУ-овом Лиценцом за
слободну документацију." does not changed at click to 'latinica' tab.
It should be converted to Latin as whole other text.


Version: 1.9.x
Severity: minor

Details

Reference
bz7605

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:28 PM
bzimport set Reference to bz7605.
bzimport added a subscriber: Unknown Object (MLST).

rotemliss wrote:

I think it's because 'copyright' is a content language message (using
wfMsgForContent), and variant may be considered an interface language. A
possible solution is making 'copyright' an interface language - after all, the
copyright should be defined in LocalSettings.php, not in the message itself.

Hmm, I thought I transliterated the MessagesSr_ec.php to MessagesSr_el.php and
that both were being used as they should be. However, as Rotem pointed out, not
all messages are being tranliterated, because some are "content" and some
"interface" messages. Can we make interface messages transliterable too, as this
in not the problem just with "copyright" message?

rotemliss wrote:

(In reply to comment #2)

Can we make interface messages transliterable too, as this in not the problem

just with "copyright" message?

Actually, the separation is not about the messages themselves, but about their
use. There are two language objects: the interface language and the content
language. The content language is the site default language, defined by the site
settings - e.g. English (en) for enwiki. The interface language is the content
language by default, but the user can change it via his preferences or the
parameter "uselang" of the URL.

The messages are used from the interface language for almost all the things, but
the content language messages are used for several things. Normally, the
interface language is used for display, and the content language is used for
things which are important for the *content*. For example, when reverting a
page, the content language message is used as an edit summary, and not the
interface language message.

However, in this case, the content language message is always used for display,
which is not good.

So, answer for your question:

  • I think you mean the content messages, as the interface messages are always used.
  • It's not possible to change the content messages for variants, because their

whole point is that they are *not* changed, and always used from the content
language. Therefore I think it makes sense to change "copyright" to be an
interface message, not a content message.

But "copyright" message is not a big deal, as it's not really an important one.
But ok, if it can be changed, go for it. Better something than nothing.

rotemliss wrote:

(In reply to comment #4)

But "copyright" message is not a big deal, as it's not really an important one.
But ok, if it can be changed, go for it. Better something than nothing.

Which messages do you want to change, then?

Anyway, 'copyright' can be changed, but I'm sure that there was a reason for
using it from the content language. A possible reason is sites which define the
copyright information in the content language, without changing other languages,
which may make users who use other languages see wrong copyright information.

Well, all :), but that is impossible. I don't know what the best solution would be.

rotemliss wrote:

(In reply to comment #6)

Well, all :), but that is impossible. I don't know what the best solution

would be.

What do you mean? For example, do you think that the edit summary of the
automatic rollback should depend on the interface language of the person who
makes the rollback? If you want it to depend on the interface language of the
person who watches the page, it's impossible – the text is written in the
database, and can't be changed in such way. These messages just use the wiki
content language, and are not just in English.

alefzet wrote:

it's impossible – the text is written in the database,

It is easy - just save in DB flag of event, or even English text as key. See exemple in Xaraya.

Well, let's take
http://sr.wikipedia.org/w/index.php?title=Special:Recentchanges&variant=sr-el
for example: We have

Pokaži poslednjih 50 | 100 | 250 | 500 promena u poslednjih 1 | 3 | 7 | 14 | 30 dana
Сакриј мале измене | Покажи ботове | Сакриј анонимне кориснике | Сакриј
пријављене кориснике | Сакриј сопствене измене
Pokaži nove promene počev od 19:18, 18. октобар 2006.
Именски простор: Обрни селекцију

Which is: latin, cyrillics, latin and cyrillics... not really good. And most of
them seem like they should be transliterated (nothing here looks like "content
message")

I am aware that edit summaries and like cannot be transliterated at this point,
but I don't see why we can't do that.. After all, just like articles, edit
summaries and log messages/comments are written to the database, right? So, the
extension can transliterate them, just like it does to the real content via
parser. Or something like that.

alefzet wrote:

Division of messages seems to 'interface' or 'content' so arbitrary. In reality for example on
Image: pages is produced garbage-like annoying mix of Latin an Cyrillic.

rotemliss wrote:

I don't see the problems you talk about. Could you please attach a screenshot of
a page with mixed characters? (Except for the copyright message, which is
discussed here. Generally, the discussion about the other messages should be
done in another bug.)

rainman wrote:

I suspect this might be a caching problem, since the problem is not there on my
local wiki (at least for me). I also found that on sr.wiki, sidebar contains
outdated messages for anonymous users (when viewed in variants). I'll look into
it in a few days, I have it on my todo list...

alefzet wrote:

(In reply to comment #11)

I don't see the problems you talk about. Could you please attach a screenshot ofa page with mixed

characters? (Except for the copyright message, which isdiscussed here. Generally, the discussion
about the other messages should bedone in another bug.)

http://img100.imageshack.us/img100/1628/cyrillicsl3.png

http://img100.imageshack.us/img100/4269/latinre6.png

rotemliss wrote:

I see the following problems in the screenshots:

  1. The image title is Latin, but is not converted to Cyrillic in sr-ec.
  2. The messages in sr-el are from sr-ec.

They seem to represent the following global problems:

  1. The page title is not converted to variants.
  2. The messages are obtained from sr-ec to sr-el.

I don't know how to handle problem 1, if it's a problem. However, I see that
problem 2 is not exist for me, so I think it's because you have a language
defined in your user preferences.

alefzet wrote:

(In reply to comment #14)

  1. The page title is not converted to variants.

It is normal for image titles. They shouldn't converted.
Yes, I logged-in sr wiki, and in my user preferences are selected both language and variant sr
(Serbian).

BTW I noticed namespace words also is not converted to Latin in pull-down lists. May be such problem
is related to magic names too?

rainman wrote:

Fixed in r17173. The problem was that user language settings were overriding the
selected variant, and thus lead to mixed messsages for logged-in users.

rainman wrote:

So, what was fixed is the problem "with other messages", i.e. the mixing of
messages (which was a major bug). If you still want the copyright messages
changed to interface message you should reopen the bug.

rotemliss wrote:

The original report was not about this problem - reopening. Thanks for fixing
it, though.

alefzet wrote:

Is possible workaround with $wgForceUIMsgAsContentMsg? See http://www.mediawiki.org/wiki/Manual:%
24wgForceUIMsgAsContentMsg

This message needs to be content language so that it contains the proper
site-specific information. Using interface language would mean it would likely
be wrong for most people using non-default interface language selections.