Use transliterator_transliterate to generate "url_key"

[sreichel]

Description (*)

@luigifab had a great idea to use intl-extension for generating url key with translating all special chars. For me the PR did not work, so tried myself.

This is a non-BC-breaking try of it. It does not change method-signaturer and should be BC-safe. (I did not add all features of #1631. That could be done in another PR.)

To not reinvent the wheel for locale-mapping if have added symfony/string that exactly does what we need.

See: https://symfony.com/doc/current/string.html#slugger

Related Pull Requests

1. See Used transliterator_transliterate to generate url_key #1631

Manual testing scenarios (*)

• have multiple store with different languages assigned (eg sample data)
• edit product title to have some locale specific character/words
  • de_DE: umlauts (äöü)
  • use trademark/copyright/etc.
• generate new url-key (e.g. changing name) ...

Test product/category before and after ...

$urlKey = 'a & B, x%, ä, ö, ü';
$model = new Mage_Catalog_Model_Product_Url();
if (method_exists($model, 'setLocale')) {
    # $locale = Mage::getStoreConfig(Mage_Core_Model_Locale::XML_PATH_DEFAULT_LOCALE, <store_id>);
    $model->setLocale('de_DE');
}
var_dump($model->formatUrlKey($urlKey));

Before url-key

'a-b-x-a-o-u'

After url-key

en_US

a-and-b-x-percent-a-o-u

de_DE

a-und-b-x-prozent-ae-oe-ue

Questions or comments

Locale config in xml should be changed to not have language-specif config in core. Any ideas?

Magento already had an unsused config for it ... Mage_Catalog_Helper_Product_Url::__construct looks for Mage::getConfig()->getNode('default/url/convert'); XML.

[fballiano]

#1631 is already merged since many months, what is the point of creating this PR when next should be released? or maybe not? this PR, if merged, will create discrepancies between the branches since IMHO do not have any reasons to exist.

[fballiano]

@colinmollenhour

[sreichel]

@fballiano

#1631 was merged to next-branch only. b/c of breaking changes (#1631 (comment)) - and it does not work. See my last comment there.

[fballiano]

I tested it on next and it was working for me.

and anyway your answer doesn't answer my question.

@colinmollenhour

[sreichel]

@fballiano

It formated the titles as explained, to default latin something, but localization never worked.

This code does not work ... b/c there is no de-de_Latn/BGN

            $opts = transliterator_list_ids();
            $code = str_replace('_', '-', strtolower($locale)) . '_Latn/BGN';
            if (in_array($code, $opts)) {

this PR, if merged, will create discrepancies between the branches since IMHO do not have any reasons to exist.

imho next branch has a not working PR in, that has to be fixed/replaced.

[colinmollenhour]

@sreichel Can you confirm if the feature is working in next? Why do we need to backport it to main? It is a BC so it should not be backported from my view as it is more of a feature than a bugfix considering the old way was accepted for many years.

[sreichel]

Its not a backport.

#1631 in next branch does not work. It only replaces some chars as state in the PRs description.

The code mentioned in https://github.com/OpenMage/magento-lts/pull/1631/files#diff-34c65e6986a386387a7489be1bb073b8b5e3f98e85cdf6e61804c3e309a56038R72-R78 does not work.

This PR changes no method signatures and should be BC-safe.

[colinmollenhour]

This PR changes no method signatures and should be BC-safe.

But doesn't it change the url slugs? Would you consider that BC?

[sreichel]

Slugs should only get generated when changing url-keys.