The hardcoding of aliases really seems more like a hack than a practical fix...

• The catid fix (obviously) is fine.
• The menutype fix looks fine as well. Sanitising is done by the table as well and looks more strict than stringUrlSafe.
• The alias fix for non-latin however needs something else. As Michael already wrote it is a hack. Imho it also counteracts the separation of text and code. Eg when you want to adjust a title, you would have to adjust the alias in code as well.
  What do you think when we just add the counter to the alias generation? Eg $article['alias'] = JApplicationHelper::stringURLSafe($article['title'] . '-' . $i);. This way in worst case you get the counter as alias but in the other cases you get a nice translated alias, just with a number following.

@mbabker @Bakual
concerning the aliases.
We can indeed do that for articles as we have alraedy a counter $i. After all I just placed it first and added sample for now.
Not a big difference with
$article['alias'] = $i . 'sample' . JApplicationHelper::stringURLSafe($article['title']);
I will do the change if it blocks the merge.

For categories, we have no counter and I do not know how to add one. We have only 2 categories.
What do you think?

My concern isn't so much the fact we need changes (nobody's perfect), rather at a glance it seems like the way some things are handled seems more like a low level hack to work around an issue than actually fixing an issue (and we have a bad history of taking the low level hacks and not coming back to fix the deeper issue).

The problem is that we have many languages using non-latin glyphs.
Therefore we have to find a solution. Without using the global transliterator (we already discussed about that and found out it is not available for all versions of PHP), there is no other way in this feature to get acceptable aliases.

Will change the alias for articles to @Bakual proposal. Not a big deal.
For categories, I have no way and it is not imho as hacky as it seems.

For categories, I have no way and it is not imho as hacky as it seems.

For categories and menuitems we could hardcode a number instead of the counter. Eg take the number that is already in the title language constant.
Thinking about it, we could also move the number suffix outside the stringUrlSafe method (stringURLSafe($article['title']) . '-' . $i). This way worst case would become 2017-09-11-16-25-32-1 instead of just 1.

seems more like a low level hack to work around an issue than actually fixing an issue

If we wanted to fix this in the stringUrlSafe method, we could add miliseconds to its fallback string generation. That could work as I doubt we add multiple articles in the same milisecond ?

Forget those comments about the datetime stuff. I somehow wrongly assumed that is generated by the stringUrlSafe method. But it's done by the table. We could of course also add something like that.
(https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Table/Content.php#L199-L204)

would not hardcoding a number be similar to hardcoding the more informative text i used? i mean as 'hacky' ?

I have tested this item ✅ successfully on 88daa64

Patch ok for me

would not hardcoding a number be similar to hardcoding the more informative text i used? i mean as 'hacky' ?

It at least separates the text from code and still allows for translated alias. But yeah, it still is a bit of a hack. If we wanted to do a real fix, we would have to change the lines in the tables and return miliseconds instead of just seconds there. That would work. Not sure if it's worth it.

In this last commit, I took off ALL hardcoded stuff and forced using unicodeslugs aliases temporarily when the language is not using latin glyphs (idea from @imanickam ).
This works in multilang as well as monolang with same testing instructions.

below examples in multilang

Results for menu items

Result for categories

Result for articles

Example of url obtained when clicking on an article title link from the blog category
/index.php/ta/வலைப்பதிவு/18-தங்கள்-வலைப்பதிவிற்கு-வரவேற்கிறோம்-ta-in

@mbabker
@Bakual
@imanickam
@AlexRed

Please test again.

I have tested this item ✅ successfully on cca4fef

I have tested this/these change/changes successfully in the following three scenarios:

(a) Install of Sample Data using the Sample Data Plugin in English (en-GB) - The back-end language was English - Mono lingual site
(b) Install of Sample Data using the Sample Data Plugin in Tamil (ta-IN) - The back-end language was Tamil - Mono lingual site
(c) Install of Sample Data using the Sample Data Plugin in Tamil (ta-IN) - The back-end language was Tamil - Multilingual site

@Bakual @AlexRed
We need a second tester

I have tested this item ✅ successfully on cca4fef

Patch ok for me

RTC after two successful tests.

OK now?