Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with html-entities in translation #1467

Closed
sgiehl opened this issue Jul 7, 2010 · 19 comments
Closed

Problem with html-entities in translation #1467

sgiehl opened this issue Jul 7, 2010 · 19 comments
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Milestone

Comments

@sgiehl
Copy link
Member

sgiehl commented Jul 7, 2010

We got some trouble with the translations returned by the API.
In some languages the translations contain html-entities.

As we do not use a browser engine to output and there is no native javascript or Titanium function to decode entities, those entities are currently displayed in mobile application.

I guess the best way to fix this issue is to extend the language api function getTranslationsForLanguage with a optional second parameter that enables decoding entities before translations are returned.

@mattab
Copy link
Member

mattab commented Jul 7, 2010

Can you list here example of html entities used?

Can we enforce the non use of these, or are they useful? Are there some in English too?

@robocoder
Copy link
Contributor

Yes, we can add a parameter to html_entity_decode().

We need the html entities because we output HTML to the browser, e.g.,

  •   & … » › >

@sgiehl
Copy link
Member Author

sgiehl commented Jul 7, 2010

We don't use translations using entities to output html characters, atm. But in some languages entities are used for other special chars, too.

see https://github.com/piwik/piwik/blob/master/lang/pt.php#L7 for example.

Using html_entity_decode() should be the easiest way. Are all translation files in UTF-8, or are some using their own charset?

@robocoder
Copy link
Contributor

Yes, there are other html entities in the non-English translations. The translation files should be UTF-8 -- I already have a script to fix these that I can run.

@mattab
Copy link
Member

mattab commented Jul 7, 2010

+1 for your solution, a new parameter

@robocoder
Copy link
Contributor

Actually, wouldn't this be considered a new format? Otherwise, I imaging some characters would still need to be escaped depending on the format.

The easiest thing might be to use format=xml instead -- since the output is (generally) already html_entity_decode()'d -- and then on the client-side, convert a small number of specific exceptions: < > & &quot&.

@robocoder
Copy link
Contributor

format=csv is also html_entity_decode()'d, and is more compact. The only tricky part is parsing multi-line fields (i.e., a quoted string that contains newlines).

@sgiehl
Copy link
Member Author

sgiehl commented Jul 8, 2010

We are using JSON format as it can be directly used in javascript. adding a new format like json-decoded or so would do it, too. but is this decoding realy needed everywhere in the api?

@mattab
Copy link
Member

mattab commented Jul 8, 2010

adding parameter to single api function sounds better, even though it will be useless for some formats. This can just be in the function comments to clarify.

@robocoder
Copy link
Contributor

Sounds hackish. Could we decode by default when format=json? (Does that break the Flash chart data feed?)

@sgiehl
Copy link
Member Author

sgiehl commented Jul 9, 2010

hm. good question. decoding by default for json format only would do it, too.

Well, both ways are even possible and I already got solutions for both.
I'll append patches. Would be nice if one solution could be implemented before 0.6.4

@sgiehl
Copy link
Member Author

sgiehl commented Jul 9, 2010

Attachment: patch for /plugins/LanguagesManager/API.php
API.php.patch

@robocoder
Copy link
Contributor

I'm leaning towards the Json.php patch. Don't bother decoding the $key. It isn't passed by reference to the anonymous function, so decoding the $key wastes CPU cycles.

@sgiehl
Copy link
Member Author

sgiehl commented Jul 10, 2010

Attachment: patch for /core/DataTable/Renderer/Json.php
Json.php.patch

@sgiehl
Copy link
Member Author

sgiehl commented Jul 10, 2010

Oh, your right. I just fixed my patch.

@mattab
Copy link
Member

mattab commented Jul 12, 2010

looks good to me

@sgiehl
Copy link
Member Author

sgiehl commented Jul 12, 2010

(In [2480]) fixes #1467 always decode entities when format is json

@mattab
Copy link
Member

mattab commented Jul 12, 2010

tests are failing. I'll leave it as an exercise to fix them :)

Actually there is at least one failure that might be unexpected:

Fail: ../tests/core/DataTable/Renderer.test.php -> Test_Piwik_DataTable_Renderer -> test_JSON_test6 -> Equal expectation fails at character 9 with [{"value":false}] and [{"value":""}] at [trunk\tests\core\DataTable\Renderer.test.php line 337]

@sgiehl
Copy link
Member Author

sgiehl commented Jul 12, 2010

(In [2483]) fixes #1467 decode entities only for strings; fixed tests

@sgiehl sgiehl added this to the Piwik 0.6.4 milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For errors / faults / flaws / inconsistencies etc. Major Indicates the severity or impact or benefit of an issue is much higher than normal but not critical.
Projects
None yet
Development

No branches or pull requests

3 participants