Hoi, I am really happy that we want to help the smaller Wikipedias with uploading their pictures. It helps when it is made easy. One of the ways in which we can make it easy is to reduce the number of choices involved. When the only choice is cc-by-sa, we only need to explain one license. When the software involved is properly localised in their language, confusion will be a lot less. One of the ways that makes a big difference to people is, when they know that a small number of messages provide exactl functionality.. The WikiReader and the mobile Wikimedia experience point in that direction. There are however two observations; it produces overhead at translatewiki.net and it helps when you target people who are actively translating for that language. What you can do is make the local upload facility available once these limited number of messages have been localised. In this way it is a reward and not depended on an arbitrary number. When these messages are the same messages as used for Commons itself ... When there are clear differences in procedure local vis a vis Commons, it makes sense to have a document in English that explains these differences. To make it less problematic to move material to Commons, it might be an idea when they can ask Commons admins / volunteers to audit material and mark material that are Commons compliant. These files can then be moved to Commons. When regularly a percentage is calculated of the material that is OK for Commons versus the total amount of messages, we provide at least a clue what will happen when they grow to big to have too much "illegal" material. Thanks, GerardM On 11 March 2010 20:14, Erik Moeller <erik(a)wikimedia.org> wrote:

On Fri, Mar 12, 2010 at 5:51 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote: Really what needs doing is the ability to upload files to commons while never leaving your local wiki. -Chad

* Dmitriy Sintsov <questpc(a)rambler.ru> [Fri, 12 Mar 2010 14:57:39 +0300]: to Hmm.. it seems that commons already uses uselang parameter. It just should use it persistantly and the parameter should be passed via the links from small wikis. Dmitriy

Casey Brown hett schreven: Imagine a user who does not speak English (you can simulate that by changing your interface language to a language you don't know). Further imagine the user is not familiar with Mediawiki (you can simulate that by changing your skin to a skin you never used before). I changed my interface to Arabic and used the Chick skin. I was completely lost. No chance to find the right menu to change the language. As all new users nowadays have SUL accounts, perhaps the default language on Commons for SUL users shouldn't be English, but the language selected at the SUL home wiki (just the default, it should of course still be changeable in the preferences). For unregistered users registering on Commons there should be a language selection menu. There already is a language selection menu, but it only changes the signup form and doesn't propagate to the preferences. It should propagate to the preferences! Additionally why do we always present English as default to unregistered users on Commons? Why don't we observe the accept-language HTTP header? That would be some easy steps to make Commons much more accessible to non-English people. Marcus Buck

On Fri, Mar 12, 2010 at 8:44 AM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote: Making uselang persist in $_SESSION wouldn't be a bad idea though (see bug 4125) -Chad

2010/3/12 Gerard Meijssen <gerard.meijssen(a)gmail.com>om>: This is not a question of flipping a switch, it's an argument why it's fundamentally hard to respect Accept-Language for anonymous users. For the same reason, making uselang persist in $_SESSION also doesn't work for anonymous users. For logged-in users, though, both should be fine. Roan Kattouw (Catrope)

2010/3/12 Marcus Buck <wiki(a)marcusbuck.org>rg>: First off, the Squid cache would need to contain one entry per language per page, rather than simply one entry per language. This means multiple entries for the same URL that are varied between based on Accept-Language (fragmentation), which in turn means the size of the Squid cache would explode: if there are, say, 20 popular languages out there that cause significant cache population (excluding English), the cache size for Commons would be roughly multiplied by 20, as would the number of render requests to the Apaches. Second, I believe that Squid currently doesn't even support this kind of fragmentation, but I may be wrong. Roan Kattouw (Catrope)

On Fri, Mar 12, 2010 at 9:58 AM, Marcus Buck <wiki(a)marcusbuck.org> wrote: That uses Memcached, not Squid. -Chad

Roan Kattouw schreef: I understand this makes caching more difficult, but did anyone ever do measurements? Without decent metrics this is just wild guessing. Things to measure for example: * Total text requests for all sites * Total text requests for just Commons * Total misses for all sites * Total misses for just Commons I'm sure someone can dig up these metrics. Worst case all text requests for Commons go to the backend directly, right? Maarten

* Aryeh Gregor <Simetrical+wikilist(a)gmail.com> [Fri, 12 Mar 2010 12:31:39 -0500]: Perhaps an uploading from small wiki to commons via api while small wiki localizes client output with it's own language messages. Or, perhaps some parts of localization can be done with Javascript (which can read cookies, too), again not altering squid caching. Dmitriy

Thanks for all the responses. I think I understand the different arguments. I'd like us to find a reasonable interim solution, especially for small wikis like the Swahili Wikipedia, where the upload link is now hidden for new users, and visiting the upload page (if you do get a link from somewhere) results in an obscure error message. How about this as an interim fix: Instead of hiding the upload link and showing an obscure error message to new users, we show the link to all logged in users, and show a more informative message to non-autoconfirmed users, something like: "Please visit the upload form on Wikimedia Commons [link to localized version] to upload files, then return here to insert them. Uploading to Wikimedia Commons makes the file available to all Wikimedia languages and projects. Files can be uploaded directly to {{SITENAME}} by more experienced users." This could be an interim solution until we have nicer Commons integration. Thoughts? -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

On Sun, Apr 4, 2010 at 2:44 AM, Roan Kattouw <roan.kattouw(a)gmail.com> wrote: Perhaps make the message that appears customizable (Mediawiki: namespace) that way they can set it to say anything they like (For example, explaining their restrictions and that they need to upload at commons instead.) -Peachey

On Fri, Mar 12, 2010 at 12:59 PM, Marcus Buck <wiki(a)marcusbuck.org> wrote: I don't have the numbers. Try asking someone like Domas Mitzuas or Tim Starling.

Roan Kattouw hett schreven: I don't think we need accept-language for logged-in users. We have preference settings for logged-in users. And if we want to improve the situation of logged-in users we should go with the idea Maarten Dammers and I proposed: Make the language set in the preferences of the home wiki the default for users who are new on Commons. I don't know how many of Commons' visitors are anonymous. But either it is many, then it is important to support them better, or it is few, then the impact cannot be great. We need some numbers! Marcus Buck

Casey Brown a écrit : Another FYI: we're planning to work on this around this Summer (we're focusing on fixing the upload workflow first). -- Guillaume Paumier Product Manager, Multimedia Usability Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

Dmitriy Sintsov wrote: SUL accounts should have a list of languages the user can (is willing to) read. When he visits a wiki, if the wiki's preferred language matches one of those, use it. Else use the most similar language to the wiki preferred language from those that the user has. Some users will probably still want an override, though.

On 03/12/2010 02:14 PM, Maarten Dammers wrote: yes, pl.wiki is going currently even further. There is a discussion to almost completely disable the possibility to upload files locally and reroute all uploads to Commons. masti

Guillaume Paumier wrote: As mentioned on commons list a cross site upload tool is in early / alpha / experimental testing: http://lists.wikimedia.org/pipermail/commons-l/2010-March/005335.html To summarize from that post you can visit: http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit… Clicking on the insert image icon, then the upload button, then wait a few seconds ... if the iframe proxy is working you should see your recent uploads to commons. Then click "upload to commons" and more waiting then you can should be able to upload to commons from en.wikipedia, once done uploading it prompts you to insert your uploaded asset into the article. Its still kind of early on in development so don't be too surprised if it does not work. But let me know if you run into issues, and I can try and iron them out. ( with the exception being IE that for session iframes which needs special p3p headers and or user invoked reduced privacy settings to work the same as the other browsers. ) peace, --michael

On Fri, Mar 12, 2010 at 5:42 PM, Thomas Dalton <thomas.dalton(a)gmail.com> wrote: Wikimedia defaults are decided by wikitech-l/Wikimedia. Specific communities can choose to opt out of those defaults if they choose. Requiring all communities to explicitly opt in to any changes would make the defaults almost impossible to change. The change requiring autoconfirmed for upload wasn't approved by all the communities individually in any case, so it wouldn't make sense to require the change back to be so approved.