Page MenuHomePhabricator

When using another language, messages of "-" that are not exist in the DB are shown as "<message>"
Closed, DeclinedPublic

Description

Author: kaikkd

Description:
When using 'uselang=xx' or setting user language,
'<shareddescriptionfollows>' appears in ImagePage.

It's too ugly.


Version: unspecified
Severity: trivial

Details

Reference
bz8821

Event Timeline

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

rotemliss wrote:

The problem seems to be caused by the fix of Bug 6126 (r14493), combined with
the recent deletion of most system messages: when a message contains just "-"
(like "shareddescriptionfollows" by default) is used, the user language is not
the content language and the DB is used, MessageCache::getMsgFromNamespace is
used regardless the existance of the message in the DB (and it *was* exist and
equal to "-" before the deletion of system messages, so the bug was hidden).
Thus, "-" is overriden by "<shareddescriptionfollows>".

I think that a fix for this bug should get the result of
MessageCache::getMsgFromNamespace to a temporary variable, and check if it's an
empty message before assigning it to $message.

robchur wrote:

We should probably also ship some default message text, e.g. "this image is from
a shared repository" or similar.

rotemliss wrote:

(In reply to comment #2)

We should probably also ship some default message text, e.g. "this image is from
a shared repository" or similar.

I think it's already exist in the message "sharedupload".

kaikkd wrote:

patch for r19687

Attached:

kaikkd wrote:

(In reply to comment #1)

You say, like attachment 3159?
I see, It works fine in this case.

rotemliss wrote:

This specific problem should be fixed in r20550. I'm not closing this bug,
though, as it's a general problem which is not specific to
"shareddescriptionfollows". Changing the summary to reflect it. See Comment 1
for a detailed explanation of this bug.

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

audreyt wrote:

Hi Kkkdc, thank you for the patch!

As you may already know, MediaWiki is currently revamping its PHP-based parser
into a "Parsoid" prototype component, to support the rich-text Visual Editor
project:

https://www.mediawiki.org/wiki/Parsoid
https://www.mediawiki.org/wiki/Visual_editor

Folks interested in enhancing the parser's capabilities are very much welcome
to join the Parsoid project, and contribute patches as Git branches:

https://www.mediawiki.org/wiki/Git/Tutorial#How_to_submit_a_patch

Compared to .diff attachments in Bugzilla tickets, Git branches are much easier
for us to review, refine and merge features together.

Each change set has a distinct URL generated by the "git review" tool, which
can be referenced in Bugzilla by pasting its gerrit.wikimedia.org URL as a
comment.

If you run into any issues with the patch process, please feel free to ask on
irc.freenode.net #wikimedia-dev and the wikitext-l mailing list. Thank you!

Isn't this yet another fallback language bug to be moved to Internationalization component?

mails2vichu wrote:

I found the MessageCache.php file in /includes/cache folder.
But i couldn't find the desired codes in those lines mentioned above.
Can you please make sure about the file path and the line number please?

Re patch review:
No longer applies, too old.

(In reply to comment #9)

Isn't this yet another fallback language bug to be moved to
Internationalization component?

Indeed it should be in i18n component


However, I can't reproduce this bug. Perhaps I misunderstand it? Is this bug still present?

yeah, definitely cannot reproduce. Closing WORKSFORME. Please repoen if still present.

(In reply to comment #12)

yeah, definitely cannot reproduce. Closing WORKSFORME. Please repoen if still
present.

Might have been solved by bug 1495 and/or bug 14176.