typo3-realurl icon indicating copy to clipboard operation
typo3-realurl copied to clipboard

Language Fallback for non-ascii languages

Open CDRO opened this issue 8 years ago • 14 comments

When using japanese or chinese (or any non-ascii supporting language), realurl will simply encode the page names to the request query.

This is quite annoying, since this will never work (this is known since some years now). There used to be an option called languageExceptionUids, but it doesn't exist anymore, so I built it again.

What has to be done to work properly is that you have to add this to the pagePath Configuration part:

'languageFallback' => [
    '6' => 1,
    '7' => 1,
],

CDRO avatar May 03 '16 14:05 CDRO

If I'm logged in into the backend, it works else not ...

ukemi-26 avatar Jun 11 '16 06:06 ukemi-26

The plan is to bring back languageExceptionUids. The pull request is not clean and cannot be merged.

dmitryd avatar Jun 20 '16 09:06 dmitryd

@dmitryd What do you mean by "the request is not clean"?

CDRO avatar Jun 20 '16 09:06 CDRO

@CRDO Check the diff. Why does it modify ext_localconf.php?

dmitryd avatar Jun 20 '16 09:06 dmitryd

This should indeed not happen, I think this is due to a local conflict.

I'll try to fix this now and make another pull request.

CDRO avatar Jun 20 '16 09:06 CDRO

This looks better now, what do you think?

CDRO avatar Jun 20 '16 09:06 CDRO

No, it doesn't :( I think you work with old sources. Please, see how ext_localconf.php looks like now: https://github.com/dmitryd/typo3-realurl/blob/development/ext_localconf.php

Please, update your copy before making a pull request to use latest file versions.

dmitryd avatar Jun 20 '16 09:06 dmitryd

Ok, now I get what I got wrong, I thought I'd revmoed them by mistake but you took care of this (sorry for the burden).

So ext_localconf.php is now in the newest version, so no conflict possible there now.

CDRO avatar Jun 20 '16 09:06 CDRO

I'll do some more work on this later because there are other places where this has to be implemented.

dmitryd avatar Jun 20 '16 13:06 dmitryd

You could also improve the Utility::convertToSafeString method. If it would transliterate the string, there would be a nicer URL.

You could either use the utf8_romanize method from dokuwiki: https://github.com/splitbrain/dokuwiki/blob/master/inc/utf8.php

Or you could use the Transliterator class from PHP (if it exists):

if (class_exists('Transliterator')) {
    $translit = \Transliterator::create('Any-Lower; Any-Latin; Latin-ASCII;');
    $processedTitle = $translit->transliterate($processedTitle);
}
Original After transliterate()
test with ßpace Änd Umlaüts test with sspace and umlauts
自由的百科全书 zi you de bai ke quan shu
ウィキペディア u~ikipedia

rvock avatar Jul 14 '16 13:07 rvock

@rvock This should be a separate pull request and it should be carefully evaluated because it may break compatibility.

dmitryd avatar Jul 14 '16 15:07 dmitryd

@CDRO languageExceptionUids is back by now but I think this PR still has value since currently it's always sys_language_uid=0 that's used for these exceptions. Being able to specify better fallbacks would be highly useful.

Imagine for example a site where German is the default language, English the 2nd language and Japanese the 3rd language. If you set languageExceptionUids accordingly, you'll get German URLs in Japanese whereas English would be a better option.

mbrodala avatar Mar 09 '17 08:03 mbrodala

@mbrodala I think you're right, this feature would be really great to have in this kind of situation.

I'll have a look at the current source code and propose a new MR in some weeks in order to cover this scenario.

CDRO avatar Mar 09 '17 08:03 CDRO

@rvock I think we do not need a transliterator that translate asian letters. As far as I see, people prefer to have them in urls.

dmitryd avatar Mar 09 '17 12:03 dmitryd