TYPO3 Core

Workaround: writing a wizard for the domain table that does the necessary translation.

Possible fix: adding code that does this translation automatically on save of a domain record.

Problem: when TYPO3 has to create a link including domains (happens ONLY in a mult-subdomain setup like sub1.domain.tld) it will output the ugly punycode version of the domain.

Since we could need this function in more than one place (lock to domain in user/group options for example) an automatic translation in both directions would be transparent to the user. This, however, would require a converter that leaves non-punycode intact, so that we could pipe every domain value through it. This will probably cost performance.

Have a look at:
http://idnaconv.phlymail.de/

You could speed-up the converter in detecting xn-- in the domain name...

TYPO3 Version too old.
The reported version is no longer maintained.

If this bug still persists in 4.0.1, please re-open it again and set the field "Product Version" to the corresponding version.

Matthias, this is ridiculous. You know very well that no support for IDN has been added in 3.8 or 4.0. You could have closed the bug even in the state "won't fix". "Fixed" is a joke.

You can try the attached patch. It used converter mentioned in one of the notes. However you also need to install patch from related bug report (5550) if you loose characters in domain name while saving domain record.

The converter itself is LGPL (which is ok) but it does not convert properly domain name with characters like exclamation mark. But this is not usually necessary.

I forgot to write that this works only with typolink (so RTE + TS setup + properly written extensions) and you need config.typolinkCheckRootline=1 in TS setup if you want to have proper links accross domains.

It will also decode domain when user comes to page. No need to change domain record, all goes on the fly.

Looking at the code the patch won't allow you to enter a IDN name in a TYPO3 domain record.

To do that I think you need a TCEmain hook that converts the domain name from current charset to UTF8 and then to IDN on saving (with a check to prevent double encoding). The drawback is that you will see the IDNA domain which is ugly. To solve this we could add a user field (for display) with a function that trnanslates the puny code into a readable name in the BE (edit form and web>list).

Martin, I do not think that anyone should put domain name in "xn--" format because it is hard to find later what it actually means. I think my solution is much better because it allows you to put real domain name (like jürgen-müller.com) and see it later in backend.

I think it can be the other way round: user field can display punycode name, just for user's convinience.

The point is that IMHO we need to store the puny code in the domain table, so TYPO3 will recognize the domain. After all that's what the browsers send over the network in their requests.

But maybe we can change the label field of the domain table to be a user field. And the form can maybe changed so that you enter a domain with accents, but it will be stored as punycode.

typo3 core will recognize the domain with my patch :) the problem can be for extensions (like realurl) but this is easily fixable.

Well, until it is approved by core, interested people can use extension, whose extension key is "punycode". It does it all transparently. typo3 4.1.x is required.

I will remove assignment to me. I did what I could: made a patch and sent it to core list. There were neither approval, nor disapproval. I do not want this bug to stay on me indefinitely.

An idea to use multibyte PHP commands instead of their single byte versions might be function overloading with set_ini() and mbstring.func_overload.

No. Use functions from t3lib_cs if you need but never mb_* functions.

So we have a huge German speaking TYPO3 market, a patch for IDN for over two years now and no approval to have it in core?

Did you vote for it?

I was actually unaware that non-core devs can vote for patches (always sticked to http://typo3.org/development/bug-fixing/resolving-bugs/). But today's dev list discussion brought up that this page is outdated. So I will test it ASAP.

I'm also not a core dev and have over 100 successful RFCs and gave probably twice as many +1 ;-) So the rule isn't that new.. (and typo3.org outdated as always..)

TYPO3 4.4.2 - and this bug still exists

Patch set 1 of change I87d275a2f3bcfd321147b6d32a5403db704bdc4d has been pushed to the review server.
It is available at http://review.typo3.org/3804

Patch set 2 of change I87d275a2f3bcfd321147b6d32a5403db704bdc4d has been pushed to the review server.
It is available at http://review.typo3.org/3804

Patch set 3 of change I87d275a2f3bcfd321147b6d32a5403db704bdc4d has been pushed to the review server.
It is available at http://review.typo3.org/3804

Patch set 4 of change I87d275a2f3bcfd321147b6d32a5403db704bdc4d has been pushed to the review server.
It is available at http://review.typo3.org/3804

Patch set 5 of change I87d275a2f3bcfd321147b6d32a5403db704bdc4d has been pushed to the review server.
It is available at http://review.typo3.org/3804

Patch set 6 of change I87d275a2f3bcfd321147b6d32a5403db704bdc4d has been pushed to the review server.
It is available at http://review.typo3.org/3804

Patch set 7 of change I87d275a2f3bcfd321147b6d32a5403db704bdc4d has been pushed to the review server.
It is available at http://review.typo3.org/3804

Patch set 8 of change I87d275a2f3bcfd321147b6d32a5403db704bdc4d has been pushed to the review server.
It is available at http://review.typo3.org/3804