Author: kaikkd
Description:
When using 'uselang=xx' or setting user language,
'<shareddescriptionfollows>' appears in ImagePage.
It's too ugly.
Version: unspecified
Severity: trivial
• bzimport | |
Jan 29 2007, 1:48 PM |
F3666: 0130.txt | |
Nov 21 2014, 9:35 PM |
Author: kaikkd
Description:
When using 'uselang=xx' or setting user language,
'<shareddescriptionfollows>' appears in ImagePage.
It's too ugly.
Version: unspecified
Severity: trivial
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:
(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.