Update internationalization support

[theduckylittle]

From the users list:

And the hard part, in every php file, all request change into urldecode
for example in identyfy.php
$visibleLayers = $_REQUEST['layers'];
into
$visibleLayers = urldecode($_REQUEST['layers']);
...
$projection = $_REQUEST['projection'];
into
$projection = urldecode($_REQUEST['projection']);
...
lot of fun ;)

These seems pretty tenable for an immediate release inclusion.

[klassenjs]

+1 on replacing escape() with encodeURIComponent() as escape() is
deprecated and doesn't always handle Unicode correctly [1].

I am not up on the PHP services, but I have to call URI.unescape() on
the parameters in my Ruby services so calling urldecode() in PHP makes
some sense.

Any objections?

[1] http://www.w3schools.com/jsref/jsref_escape.asp

[klassenjs]

I tested replacing escape() with encodeURIComponent() and there is an issue.

While more correct, it does break existing services (such as select.php)
because encodeURIComponent() escapes more characters than escape(). In
this particular case the "/" being replaced by "%2F" in select_layer is
causing select.php to return 500.

Clearly, the select.php (and other services included in the GeoMoose
Demo) should be updated to call urldecode() where appropriate. My
concern is what this change may break existing custom services.

(And a second concern, the select.php service should probably validate
its parameters instead of dieing with a 500).

I have a patch for Service.js and untested patches for the PHP services
if someone wants them as a starting point.

[theduckylittle]

Adding urldecode is actually a bad thing: http://www.php.net/manual/en/function.urldecode.php

[klassenjs]

Make sure the JS code isn't double encoding. IIRC it wasn't working on '/'
without the urldecode.
On Apr 27, 2014 3:11 PM, "theduckylittle" notifications@github.com wrote:

Adding urldecode is actually a bad thing:
http://www.php.net/manual/en/function.urldecode.php

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-41507452
.

[theduckylittle]

Found the issue with the double encoding, also found what I suspect is the source of the print bug, and I'm hoping that all of that pushed properly.

[theduckylittle]

I just spent an afternoon learning a lot more about PHP character set encoding than I had intended. We can now handle UTF-8 and should be able to handle other encodings.

[theduckylittle]

Testing process:

1. Edit local_settings.ini, change the "output-encoding" to 'LATIN1' and input-encoding to 'UTF-8' as its the encoding of the international shapefile.
2. Uncomment "international/testing" from the demo catalog.
3. Reload the UI and use identify to click on the various boxes. When set correctly the boxes should identify as Mädchen, Girl!, Garçon, and Niña.

There is also a test in tests/query_php_test.php:QueryTest.test_utf8 which will test for the appropriate back-end functionality.