Wikimedia Bugzilla is closed!

> via link & url-parameter

Which browser, browser version, and operating system is this about?

I tried it personal on Win 8.1, Chrome (33.0.1750.5 & 31.0.1650.67), FF 26 & IE11, there are at least two other people having the same problem (see https://de.wikipedia.org/wiki/Benutzer_Diskussion:AleXXw#Denkmallisten)

This is a bug in the monument list tool; the proper URL would be https://commons.wikimedia.org/wiki/special:UploadWizard?campaign=wlm-at&id=35863&description=Puttererschl%C3%B6ssl%20mit%20Schlosskapelle&debug=1 (note the two-byte code for ö). This is percent-encoded UTF-8; the tool seems to be outputting unencoded links in an ISO-8859-1 encoded document (which the browser then turns into percent-encoded ISO-8859-1).

1) Sorry, it worked for years now so there is a new and existing problem that needs to be fixed. 

2) Mediawiki accepts two-byte codes: linked via
https://de.wikipedia.org/w/index.php?title=Liste_der_denkmalgesch%FCtzten_Objekte_in_Aigen_im_Ennstal&redirect=no&#objektid-35863, so the problem seems to be at the UploadWizzard

3) I don't think I have any possibility to change the encoding. The current code to create the link is:

{{fullurl:commons:special:uploadWizard|campaign=wlm-at&id={{{ObjektID|}}}&descriptionlang=de&description={{urlencode:{{{Name}}}}}{{#if:{{{Commonscat|}}}|&categories={{urlencode:{{{Commonscat|}}}}}}}}}

Any better ideas? BTW: this issue doesn't just belong to this one template, every template on de.wp using upload campaigns is now broken.

(In reply to comment #4)
> 2) Mediawiki accepts two-byte codes: linked via
> https://de.wikipedia.org/w/index.
> php?title=Liste_der_denkmalgesch%FCtzten_Objekte_in_Aigen_im_Ennstal&redirect
> =no&#objektid-35863,
> so the problem seems to be at the UploadWizzard

Try the same link on the Greek Wikipedia:
https://el.wikipedia.org/w/index.php?title=Liste_der_denkmalgesch%FCtzten_Objekte_in_Aigen_im_Ennstal&redirect=no&#objektid-35863

There is no way to reliably identify what character %FC stands for. ISO-8859 encodings only allow for 256 characters, therefore each region has its own character set and the same byte means a different character in different regions. Single-language wikis can be matched to encodings but multilanguage wikis like Commons cannot.

More importantly, if your application uses ISO-8859-1 then it will make a mess of any character that is not in that character set. (What if there is a monument in Austria which has a č in its name? That is encoded in ISO-8859-x as %E8, which happens to be è in ISO-8859-1.) So this is a bug in the monument list tool regardless of whether UploadWizard understands the links; and if that bug is fixed, there will be no problem with UploadWizard either. As it is now, I think it is better to error out on ambiguous input than to choose one possible interpretation by random and possibly do something else than the uploader intended.

> 3) I don't think I have any possibility to change the encoding. The current
> code to create the link is:
> 
> {{fullurl:commons:special:uploadWizard|campaign=wlm-
> at&id={{{ObjektID|}}}&descriptionlang=de&description={{urlencode:
> {{{Name}}}}}{{#if:{{{Commonscat|}}}|&categories={{urlencode:
> {{{Commonscat|}}}}}}}}}

That code works fine, it generates UTF-8 links, and UploadWizard works for me when I click them. The problem is only with the application at the toolserver.

As comment 5 explains, it is technically impossible to fix this in UploadWizard to make it "work for everybody".

Tentatively moving to WLM product (though that does not feel right either, but it's at least closer to where this should get fixed).

Thanks for the help, even if noone has changed anything: now it works again from the wikilists ;) The toolservertool was never the problem, there was a broken link on the on-wiki-lists.