Add Locale::getDisplayKeyword and Locale::getDisplayKeywordValue functions

It passed 18 to 0, with 2 abstaining, clearing the two-thirds majority it needed. Voting closed on June 23, 2026. The RFC targeted PHP 8.6, and the page marks it as implemented.

A locale can carry extra settings called keywords. For example, de_DE@collation=phonebook means German with phone book sort order. PHP could already extract those keywords with Locale::getKeywords(), but it had no way to show their names in a human language. This RFC from Weilin Du adds two methods to the intl extension to fill that gap.

Show me#

Locale::getDisplayKeywordValue() turns a keyword's value into a readable label:

Locale::getDisplayKeywordValue(
    'de_DE@collation=phonebook',
    'collation',
    'en'
); // "Phonebook Sort Order"

Locale::getDisplayKeyword() does the same for the keyword's name, like collation or calendar:

Locale::getDisplayKeyword('collation', 'en');
// the English label for "collation"

Each method also gets a procedural function version:

• locale_get_display_keyword()
• locale_get_display_keyword_value()

Why add them#

PHP already has a family of Locale::getDisplay*() methods, like getDisplayLanguage() and getDisplayRegion(). Each one wraps a function from ICU, the Unicode library that intl is built on, and these two ICU functions were the only ones in that family PHP didn't expose.

Without them, you'd have to maintain your own list of labels for keywords and values, even though ICU already has that data.

How it works#

The new methods follow the same conventions as the other display methods:

• The last argument is the display language. If it's null, PHP uses the default locale.
• If ICU fails, the method returns false and reports the error the usual intl way.
• A string containing a NUL byte throws a ValueError.

Small ICU additions like this have gone in without an RFC before. This time, after talking with the extension's maintainer, it went through the RFC process.

What it means for existing code#

Nothing breaks. The only risk is if your code already declares a global function with one of the new names.