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

Tag-specific templates don't work when containing umlauts #478

Closed
Konzertheld opened this issue Feb 19, 2013 · 6 comments
Closed

Tag-specific templates don't work when containing umlauts #478

Konzertheld opened this issue Feb 19, 2013 · 6 comments
Milestone

Comments

@Konzertheld
Copy link
Member

$contenttype.tag.$tag.php template files are supposed to match posts tagged with $tag. They do, unless $tag contains an umlaut. Please try to reproduce it as it might be server-related.

@chrismeller
Copy link
Member

When var_dumping several points in the Theme::display_fallback and RawPHPEngine::template_exists methods I see something quite... odd:

In the list of available templates:
0 => string 'entry.tag.fällen' (length=18)

But then in the actual loop seeing if each fallback exists:
string 'entry.tag.fällen' (length=17)

Unless I have somehow typo'd entry.tag. in one of them and my eyes are playing a trick on me, I'd say we have some sort of multibyte string manipulation problem.

@MattRead
Copy link
Member

in your first paste:
ä: U+00E4 LATIN SMALL LETTER A WITH DIAERESIS Ll

in your second:
ä: U+0061 LATIN SMALL LETTER A Ll U+0308 COMBINING DIAERESIS
Mn

combiner problems. We prolly need to normalize the utf strings before
comparison.

On 19/02/2013 11:44 AM, Chris Meller wrote:

When |var_dump|ing several points in the |Theme::display_fallback| and
|RawPHPEngine::template_exists| methods I see something quite... odd:

In the list of available templates:
|0 => string 'entry.tag.fällen' (length=18)|

But then in the actual loop seeing if each fallback exists:
|string 'entry.tag.fällen' (length=17)|

Unless I have somehow typo'd |entry.tag.| in one of them and my eyes
are playing a trick on me, I'd say we have some sort of multibyte
string manipulation problem.


Reply to this email directly or view it on GitHub
#478 (comment).

@chrismeller
Copy link
Member

Well, without being able to require the intl extension, which is not widely available, that means we have to include our own conversion lists. We could include the ICU lists used by the intl extension, but that means a lot of extra text for not much gain for a lot of our userbase.

@Konzertheld
Copy link
Member Author

Possibly related #488

@Konzertheld
Copy link
Member Author

Setting this to 0.11 because I feel like it. We should use 0.11 to get rid of all these i18n issues, I remember more than this and the linked one above.

@Konzertheld
Copy link
Member Author

Fixed as of habari/system@db0b0f6 on PHP 7.0.13 (though I do not know where it came from and what fixed it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants