Hi all,
it has been requested [1] that we localize "File:" in the wikitext that MediaViewer suggests for embedding the image on a wiki page, so that for example in the French Wikipedia the text would be [[Fichier:...]] instead of [[File:...]].
Turns out this is problematic, since users might want to use the text on a different wiki which has a different content language, and the namespace name would not be recognized, while File works everywhere.
I can see three options:
1. use localized namespace name, accept that it will break when users try to use it cross-wiki 2. use canonical (English) namespace name 3. use [[{{subst:ns:File}}:...]] which will translate into the local namespace name when the page is saved.
1 seems like a bad option overall; 2 might go against community standards; 3 feels like a hack and makes newbies' first meeting with wikitext more traumatic than it has to be. We are hesitating between option 2 and 3; we would welcome comments on which one would be preferred by editors.
Quick gut feel answer - IMO it should be localized in local, monolingual project invocations of media viewer (dewiki, frwiki, etc.) and canonical on multilingual wikis (Meta, Commons). If you're in dewiki and frwiki and copy wikitext, you'll most likely want to use it on that wiki, and the common expectation is to use the localized namespace prefix. If you're doing cross-wiki work, you can either go to Commons or adapt the namespace prefix. Optimize for the common case.
On Mon, May 05, 2014 at 12:13:48PM -0700, Erik Moeller wrote:
Quick gut feel answer - IMO it should be localized in local, monolingual project invocations of media viewer (dewiki, frwiki, etc.) and canonical on multilingual wikis (Meta, Commons). If you're in dewiki and frwiki and copy wikitext, you'll most likely want to use it on that wiki, and the common expectation is to use the localized namespace prefix. If you're doing cross-wiki work, you can either go to Commons or adapt the namespace prefix. Optimize for the common case.
There's a problem: How do we know where the multi-lingual wikis are?
Commons siteinfo [0] returns lang="en" which would give us the "right" result technically, but not for the right reasons (which is a red flag to me, especially when a likely answer is "special-case Commons", which Erik should know I hate doing)
Using English in the wikitext may make things slightly more confusing for some users, but it will make it way less confusing for anyone doing cross-wiki work. Not being able to recognize the string "File:" as an image transclusion is bad, but your image transclusion not working at all is even worse.
In the Mystical Future, VE will handle it all transparently anyway. Let's just make it *work*, then let VE make it easier on editors.
[0] http://commons.wikimedia.org/w/api.php?action=query&prop=revisions&m...
I would also recommend that we optimize for option 2 and use canonical (English) namespace name for all files hosted on Commons, which is the primary use case.
In the current implementation of the Embed feature, we almost always link to the file on Commons, where it can be read easily with the ‘File:’ prefix, even if you have set preferences to a different language ( https://commons.wikimedia.org/wiki/File:Pair_of_Merops_apiaster_feeding.jpg?... ).
But in the less frequent cases when a file is not hosted on Commons (or another multilingual site), but is hosted on a local language-specific site, I agree with Erik that it would be best if we could use the commonly-used prefix on that site.
Is such a hybrid approach feasible in the near-term, given all that’s on our plate? If it’s too complex to implement with current resources, then I would optimize for the first use case above.
Fabrice
On May 5, 2014, at 12:13 PM, Erik Moeller erik@wikimedia.org wrote:
Quick gut feel answer - IMO it should be localized in local, monolingual project invocations of media viewer (dewiki, frwiki, etc.) and canonical on multilingual wikis (Meta, Commons). If you're in dewiki and frwiki and copy wikitext, you'll most likely want to use it on that wiki, and the common expectation is to use the localized namespace prefix. If you're doing cross-wiki work, you can either go to Commons or adapt the namespace prefix. Optimize for the common case.
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation _______________________________________________
On May 5, 2014, at 12:08 PM, Gergo Tisza gtisza@wikimedia.org wrote:
Hi all,
it has been requested [1] that we localize "File:" in the wikitext that MediaViewer suggests for embedding the image on a wiki page, so that for example in the French Wikipedia the text would be [[Fichier:...]] instead of [[File:...]].
Turns out this is problematic, since users might want to use the text on a different wiki which has a different content language, and the namespace name would not be recognized, while File works everywhere.
I can see three options:
- use localized namespace name, accept that it will break when users try to use it cross-wiki
- use canonical (English) namespace name
- use [[{{subst:ns:File}}:...]] which will translate into the local namespace name when the page is saved.
1 seems like a bad option overall; 2 might go against community standards; 3 feels like a hack and makes newbies' first meeting with wikitext more traumatic than it has to be. We are hesitating between option 2 and 3; we would welcome comments on which one would be preferred by editors.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=64710 _______________________________________________ Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
_______________________________
Fabrice Florin Product Manager Wikimedia Foundation
On Mon, May 5, 2014 at 3:41 PM, Fabrice Florin fflorin@wikimedia.org wrote:
I would also recommend that we optimize for option 2 and use canonical (English) namespace name for all files hosted on Commons, which is the primary use case.
Doesn't it matter more where the file is _displayed_ rather than where it's hosted?
As a user, if I'm displaying a file in its German Wikipedia context, chances are pretty good I'll want to embed it in a German Wikipedia article, irrespective of whether the file is hosted on Commons. And there, people will be annoyed if I embed it as [[File:]] rather than [[Datei:]].
In any case, this seems like a case where whatever the community preference is should just win (with the possible exception of the newbie-unfrlendly option 3) from a product perspective.
Erik
On 5 May 2014 15:51, Erik Moeller erik@wikimedia.org wrote:
On Mon, May 5, 2014 at 3:41 PM, Fabrice Florin fflorin@wikimedia.org wrote:
I would also recommend that we optimize for option 2 and use canonical (English) namespace name for all files hosted on Commons, which is the primary use case.
Doesn't it matter more where the file is _displayed_ rather than where it's hosted?
As a user, if I'm displaying a file in its German Wikipedia context, chances are pretty good I'll want to embed it in a German Wikipedia article, irrespective of whether the file is hosted on Commons. And there, people will be annoyed if I embed it as [[File:]] rather than [[Datei:]].
In any case, this seems like a case where whatever the community preference is should just win (with the possible exception of the newbie-unfrlendly option 3) from a product perspective.
If I'm looking at an image hosted on Commons on the German Wikipedia and copy the wikitext to paste it into an article on the Spanish Wikipedia (which is quite likely – say I'm helping improve the Spanish article based on the existing excellent German one, and am hoping to re-use some of the images), then (a) it won't work if you use "Datei:", and (b) I don't think the Spanish community would be particularly happy that the wishes of the German community were respected over the wishes of the Spanish community for the wikitext to actually work. :-)
As a user, the most important thing is that it works correctly. Everything else is a bonus.
J.
On Mon, May 5, 2014 at 4:00 PM, James Forrester jforrester@wikimedia.org wrote:
If I'm looking at an image hosted on Commons on the German Wikipedia and copy the wikitext to paste it into an article on the Spanish Wikipedia (which is quite likely – say I'm helping improve the Spanish article based on the existing excellent German one, and am hoping to re-use some of the images), then (a) it won't work if you use "Datei:", and (b) I don't think the Spanish community would be particularly happy that the wishes of the German community were respected over the wishes of the Spanish community for the wikitext to actually work. :-)
Yeah, I get that this scenario is the one we're trying to prevent - I wonder which one is more common in practice. It also seems we're using the locally used caption as part of the embed markup, so that part would need to be adapted anyway.
Since this is just a panel that's available on-demand anyway, perhaps having an additional dropdown switch to select English/canonical vs. project-local namespaces/keywords would be handy if it can be made not too clutter-y. Example:
[ Use German language markup - works on this wiki ^ ] Use English language markup - works on any wiki
This would only be shown on wikis with non-English content language.
On 5 May 2014 15:34, Mark Holmquist <mtraceur@member.fsf.orgjavascript:_e(%7B%7D,'cvml','mtraceur@member.fsf.org');
wrote:
In the Mystical Future, VE will handle it all transparently anyway. Let's just make it *work*, then let VE make it easier on editors.
To clarify, we're thinking about adding some special handling in VisualEditor's paste for the HTML of images from a MediaWiki instance, probably via a special custom attribute VE would sniff for, that would make VE try to find the image from Commons.
This would mean that the HTML given for "hot linking" from Commons (or other wiki) for use in WordPress etc. would also transparently work in VE.
J.
Dear James,
Thanks for clarifying your goals for supporting HTML embed codes in VE — it's music to my ears :)
Now that Media Viewer is about to be released on all wikis, it would be wonderful if VE could start accepting such HTML embed codes sooner rather than later.
Is there any chance that the VE team might consider making this a high priority feature in coming weeks?
We would all be very grateful if you could take this on, and would be happy to support you in any way we can :)
For the record, here is the Mingle ticket we’re using to track this collaboration between our teams: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/500
Thanks again for all your help with this project.
Fabrice
On May 5, 2014, at 4:56 PM, James Forrester jforrester@wikimedia.org wrote:
On 5 May 2014 15:34, Mark Holmquist mtraceur@member.fsf.org wrote: In the Mystical Future, VE will handle it all transparently anyway. Let's just make it *work*, then let VE make it easier on editors.
To clarify, we're thinking about adding some special handling in VisualEditor's paste for the HTML of images from a MediaWiki instance, probably via a special custom attribute VE would sniff for, that would make VE try to find the image from Commons.
This would mean that the HTML given for "hot linking" from Commons (or other wiki) for use in WordPress etc. would also transparently work in VE.
J.
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
-- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
_______________________________
Fabrice Florin Product Manager Wikimedia Foundation
On 5 May 2014 17:33, Fabrice Florin fflorin@wikimedia.org wrote:
Dear James,
Thanks for clarifying your goals for supporting HTML embed codes in VE — it's music to my ears :)
Now that Media Viewer is about to be released on all wikis, it would be wonderful if VE could start accepting such HTML embed codes sooner rather than later.
Is there any chance that the VE team might consider making this a high priority feature in coming weeks?
We would all be very grateful if you could take this on, and would be happy to support you in any way we can :)
For the record, here is the Mingle ticket we’re using to track this collaboration between our teams: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/500
Thanks again for all your help with this project.
Of course, Fabrice – always happy to help.
I've just created https://bugzilla.wikimedia.org/show_bug.cgi?id=64935 for tracking this from the VE end; right now we're mostly in a "bug fixing" rather than "new feature" phase, but I'll see if this is something we could do quickly.
J.
Wonderful.
Thanks so much for your willingness to consider this.
I completely understand the ‘bug fixing’ mode you’re in — we’re in pretty much the same boat. :)
However, this particular issue would seem worth fixing from both ends, as it will be perceived as a broken workflow by our users — rightly so.
I have added your Bugzilla URL to our ticket, and recommend we stay in close touch on this in coming weeks.
Cheers,
Fabrice
On May 5, 2014, at 5:53 PM, James Forrester jforrester@wikimedia.org wrote:
On 5 May 2014 17:33, Fabrice Florin fflorin@wikimedia.org wrote: Dear James,
Thanks for clarifying your goals for supporting HTML embed codes in VE — it's music to my ears :)
Now that Media Viewer is about to be released on all wikis, it would be wonderful if VE could start accepting such HTML embed codes sooner rather than later.
Is there any chance that the VE team might consider making this a high priority feature in coming weeks?
We would all be very grateful if you could take this on, and would be happy to support you in any way we can :)
For the record, here is the Mingle ticket we’re using to track this collaboration between our teams: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/500
Thanks again for all your help with this project.
Of course, Fabrice – always happy to help.
I've just created https://bugzilla.wikimedia.org/show_bug.cgi?id=64935 for tracking this from the VE end; right now we're mostly in a "bug fixing" rather than "new feature" phase, but I'll see if this is something we could do quickly.
J.
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
_______________________________
Fabrice Florin Product Manager Wikimedia Foundation
Hi Erik,
For practical reasons, all shared and embed links now go to the original Commons file page (or other file repository), rather than the article where the file was initially found.
The reason for this approach is that we cannot currently guarantee that the file would display if the article name is changed at any point. We looked into a possible solution to that issue, but concluded that it would require significant development, as well as the involvement of our operations team, which already has too much on its plate.
So for now, these links go to Commons (or, in fewer cases, to the original file repository).
Given that we are winding down feature development on Media Viewer, I am not convinced that this is the most important issue we should be working on at this time, with the limited hours we have left on this product. So I would recommend implementing an expedient solution for now, rather than the more complex solution we all want in the future.
-f
On May 5, 2014, at 3:51 PM, Erik Moeller erik@wikimedia.org wrote:
On Mon, May 5, 2014 at 3:41 PM, Fabrice Florin fflorin@wikimedia.org wrote:
I would also recommend that we optimize for option 2 and use canonical (English) namespace name for all files hosted on Commons, which is the primary use case.
Doesn't it matter more where the file is _displayed_ rather than where it's hosted?
As a user, if I'm displaying a file in its German Wikipedia context, chances are pretty good I'll want to embed it in a German Wikipedia article, irrespective of whether the file is hosted on Commons. And there, people will be annoyed if I embed it as [[File:]] rather than [[Datei:]].
In any case, this seems like a case where whatever the community preference is should just win (with the possible exception of the newbie-unfrlendly option 3) from a product perspective.
Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
_______________________________
Fabrice Florin Product Manager Wikimedia Foundation
On Mon, May 5, 2014 at 3:51 PM, Erik Moeller erik@wikimedia.org wrote:
Doesn't it matter more where the file is _displayed_ rather than where it's hosted?
Indeed. There are three use cases:
1) user looks at image on Commons, wants to reuse it on some other wiki 2) user looks at image on some wiki, wants to reuse it there in a different article 3) user looks at image on some wiki, wants to reuse it on another wiki
Showing the namespace in the content language would break 3. Showing it in English would inconvenience 2. Using the subst trick has the optimal result in terms of saved wikitext (assuming all communities prefer localized namespace prefixes to English ones) but looks scary.
3 would typically happen when someone browses the interwiki links to find more content for an article. 2 is probably more frequent on large wikis which have properly categorized local uploads.
The same question could be asked about the "thumb" keyword in the wikicode of the thumbnail, although that one probably does not get translated as often.
On 05/06/2014 12:51 AM, Erik Moeller wrote:
there, people will be annoyed if I embed it as [[File:]] rather than [[Datei:]].
You could use Unicode letter U+1F4F7 ('camera') as a synonym for that namespace on all languages:
[[📷:myfilename.jpg|...]]
If you insist on "file" (rather than picture/image), there is also a 'floppy disk' character (U+1F4BE, 💾). But who remembers floppy disks in this century...
But then, are there also Unicode symbols for "thumbnail", "upright", and the other wanted keywords?
Since this is just a panel that's available on-demand anyway, perhaps having an additional dropdown switch to select English/canonical vs. project-local namespaces/keywords would be handy if it can be made not too clutter-y.
These kind of choices seem more natural for me to be made when using the data rather than when it is collected. That is: I copy a code that can be used anywhere ("File"), when I paste it into a German wikipedia it either: (a) gets adapted automatically, (b) gets adapted and provides a choice to undo the automatic adaptation or (c) is not modified but an option is provided to do so.
This is how copy&paste works in many places with respect to paste with format, or in plain text. Putting those decisions upfront seems like unnecessary cognitive load.
Pau
On Tue, May 6, 2014 at 8:28 AM, Lars Aronsson lars@aronsson.se wrote:
On 05/06/2014 12:51 AM, Erik Moeller wrote:
there, people will be annoyed if I embed it as [[File:]] rather than [[Datei:]].
You could use Unicode letter U+1F4F7 ('camera') as a synonym for that namespace on all languages:
[[📷:myfilename.jpg|...]]
If you insist on "file" (rather than picture/image), there is also a 'floppy disk' character (U+1F4BE, 💾). But who remembers floppy disks in this century...
But then, are there also Unicode symbols for "thumbnail", "upright", and the other wanted keywords?
-- Lars Aronsson (lars@aronsson.se) Aronsson Datateknik - http://aronsson.se
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Pau Giner, 06/05/2014 09:05:
when I paste it into a German wikipedia it either: (a) gets adapted automatically, (b) gets adapted and provides a choice to undo the automatic adaptation or (c) is not modified but an option is provided to do so.
None of these is possible unless you convert from canonical (English) to localised, cf. bug 41845 (note, Daniel proposed something to make multilingual wikis special, as perhaps Mark was thinking: https://bugzilla.wikimedia.org/show_bug.cgi?id=41845#c8 ).
Anyway, I'm a bit puzzled by this discussion. Content language has always worked, why change? If something makes existing workflows broken, then something is probably wrong.
Nemo
Why doesn't the step where we save wikitext entered by someone on an article automatically substitute "File:" for the localized version upon save? This would be friendlier to people who are new to using wikitext. Even better if the localized version of "File:" in any language would be automatically converted to the current wiki's. The latter would certainly solve all the issues, it would allow us to display the localized wikitext in Media Viewer's "share" according to the site's language or even the viewer's language settings, regardless of which wiki they're on. Then when they use it on a different wiki, it would automatically be subtituted for the one approved by the community they're contributing to. I'm not talking about a redirect like 41845 , I'm talking about rewriting the wikitext automatically on save.
Given my limited experience of editing articles, if I was entering things manually and writing "File:" (or the equivalent in a language I speak), I'd be pretty put off if it didn't work on the wiki I'm editing or if some community members told me that it's not the right syntax for this wiki and that I need to fix it. It seems like an unnecessary detail that a casual contributor shouldn't have to worry about. It should just magically work.
On Tue, May 6, 2014 at 9:12 AM, Federico Leva (Nemo) nemowiki@gmail.comwrote:
Pau Giner, 06/05/2014 09:05:
when I paste it into a German wikipedia it either: (a) gets adapted
automatically, (b) gets adapted and provides a choice to undo the automatic adaptation or (c) is not modified but an option is provided to do so.
None of these is possible unless you convert from canonical (English) to localised, cf. bug 41845 (note, Daniel proposed something to make multilingual wikis special, as perhaps Mark was thinking: https://bugzilla.wikimedia.org/show_bug.cgi?id=41845#c8 ).
Anyway, I'm a bit puzzled by this discussion. Content language has always worked, why change? If something makes existing workflows broken, then something is probably wrong.
Nemo
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Gilles Dubuc, 06/05/2014 09:33:
Why doesn't the step where we save wikitext entered by someone on an article automatically substitute "File:" for the localized version upon save?
That would be called a pre-save transform.
Given my limited experience of editing articles, if I was entering things manually and writing "File:" (or the equivalent in a language I speak) [...] It should just magically work.
It does work: canonical and content language are both perfectly valid wikitext. Some wikis may have different preferences on what version to use and normalise the wikitext via bots if they care a lot, but I've never heard of someone so crazy as to blame users using aliases.
Of course that would change if suddenly people were allowed to use a random language among 300 in wikitext. In that case you can expect guidelines would pop up everywhere restricting which languages you're actually expected to use.
Nemo
multimedia@lists.wikimedia.org