Last modified: 2012-12-10 20:36:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T43116, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41116 - VisualEditor: Unicode in links is percent-encoded when saved as wikitext
VisualEditor: Unicode in links is percent-encoded when saved as wikitext
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
Data Model (Other open bugs)
unspecified
All All
: High normal
: VE-deploy-2012-12-10
Assigned To: Trevor Parscal
: i18n
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-17 17:10 UTC by Hat600
Modified: 2012-12-10 20:36 UTC (History)
8 users (show)

See Also:
Web browser: Firefox
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Hat600 2012-10-17 17:10:50 UTC
when adding a link with Chinese characters, [[天安门广场]] in wikitext, the unicode character in the wikilink are percent-encoded, and the result i get after saving is [[%E5%A4%A9%E5%AE%2589%E9%2597%A8%E5%B9%BF%E5%9C%BA|天安门广场]]. 

it seems to be linked with the browser. my browser is firefox 14.0.1. the link added by others before are also encoded. see 
http://www.mediawiki.org/w/index.php?diff=594584
Comment 1 Liangent 2012-10-17 17:19:53 UTC
This does not happen in Chromium. From developer I see, in Firefox, href of a[rel=mw:WikiLink] is urlencoded in generated DOM but in Chromium it is not.

The second issue is bug 40004.
Comment 2 Liangent 2012-10-17 17:20:36 UTC
*developer tool
Comment 3 Liangent 2012-11-20 05:31:56 UTC
Per bug 41152 , the Parsoid team decide to keep non-urlencoded form in <a href=" "> so VisualEditor shouldn't send an encoded form for newly created links, at least by default (except when user manually input an encoded link target).
Comment 4 Trevor Parscal 2012-12-06 22:40:40 UTC
Whatever patch we make, it's going to depend on I9cb862f8498ba62ad7fc7669d70ea2b8e2eddbef and whatever additional patch comes after it to finish fixing what that didn't quite accomplish.
Comment 5 Trevor Parscal 2012-12-07 01:04:47 UTC
I5e1de9244d727641c10b6f0a89acc61afba7ecad looks to be the commit that will resolve the dependency - it's not the whole solution and it's not done yet though, so don't go and resolve this bug just yet.
Comment 6 Krinkle 2012-12-10 19:14:57 UTC
(In reply to comment #5)
> I5e1de9244d727641c10b6f0a89acc61afba7ecad looks to be the commit that will
> resolve the dependency - it's not the whole solution and it's not done yet
> though, so don't go and resolve this bug just yet.

That change was abandoned, I45fb3206 is the successor (and has been merged).
Comment 7 James Forrester 2012-12-10 20:36:59 UTC
Confirmed fixed in master.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links