Service Guidelines

Announcements
1

Hello folks!

With our newest update to the slug-creation system we have noticed some inconsistencies regarding service names and service slugs.

We have completely renamed russian services to their alphanumeric equivalent.

So please, when submitting or creating a service, please mind these guidelines:

  1. From now on we only support Latin-script characters in services.
    • You can still use brackets, dashes, underscores, spaces, etc.
  2. Service slugs do not support non alpha numeric characters anymore.
    Spaces will be replaced with underscores and any other non-alphanumeric char will be removed
    • My Awesome Service = my_awesome_service
    • Terms of Service; Didn’t Read = terms_of_servicedidnt_read

This does not mean we do not support russian, chinese or arabic services anymore. For compability reasons with our API and Systems we have to go this way.

2 Likes
2

If I understood well, services must from now on be on alphanumeric characters in Phoenix.
Does Latin-script include some special characters such as Á,á,É,é,Í,í,Ó,ó,Ú,ú, ö,ü,Ñ,ñ,À,à,È,è,Ì,ì,Ò,ò,Ù,ù,Ă,ă,Ĕ,ĕ,Ĭ,ĭ,Ŏ,ŏ,Ŭ,ŭ,Â,â,Ê,ê,Î,î,Ô,ô,Û,û,Ā,ā,Ē,ē,Ῑ,ī,Ō,ō,Ū,ū,A̧,a̧,Ȩ,ȩ,Ç,ç,Ş,ş,Ţ,ţ ?
These are often present on some latin languages, and it may become difficult to understand the pronunciation of the services if they are replaced by a compatible character (like Service Eksi Sozluk (ToS;DR Phoenix) and Service Associação de Defesa da Privacidade Digital (ToS;DR Phoenix))

Also, do we need to rename the non-alphanumeric services remaining? I’ve noticed, that for instance Service Однокла́ссники (Ok.ru) (ToS;DR Phoenix) and Service Tencent QQ (腾讯QQ) (ToS;DR Phoenix) are still written in characters that may not be compatible with the API.

3 Likes
3

Thanks for your input.

It‘s fine to use these characters as long as there are Alpha characters as well. (Special characters get deleted, so in an all russian service you‘d end up with an empty slug)

Tencents QQ is compatible as there are non Special characters before the chinese part = tencent_qq

Service Ekşi Sözlük would convert to eki_szlk so its up to you if the slug is still distinguishable

2 Likes
4

So Odnoklassniki - Wikipedia 's slug would be okru currently?

2 Likes
5

If you enter the russian equivalent: Yes

However I would go with Odnoklassniki (thats what I did with the other russian services) so the slug would be odnoklassniki

2 Likes
6

Just checked: The slug is _okru

1 Like
7

I am not a speaker of that language, so I cannot ascertain that. But I would suggest that when making a slug, accented characters should be converted to their non-accented counterparts instead of being discarded. Also, some languages, like German, may have specific rules for those situations (e.g. “ä” → “ae”, “ö” → “oe”, “ü” → “ue”, “ß” → “ss”, etc.).

In practical terms, I think slugging should be solved by a specific slugging library that would handle all those corner cases. If we were using Python, I would suggest slugify. According to the README, even Chinese Mandarin characters are not discarded but converted to latin characters when making a slug:

txt = '影師嗎'
r = slugify(txt)
self.assertEqual(r, "ying-shi-ma")

And also Russian Cyrillic characters:

txt = 'Компьютер'
r = slugify(txt)
self.assertEqual(r, "kompiuter")

However, you’re using PHP, with which I am unfamiliar, so I don’t have any libraries to recommend.

3 Likes
8

This is definitely possible!

Though not with your library as we are using ruby, but since RoR provides a native way to convert these characters, I’ll look into this! Would you mind opening an issue on Github about this?

2 Likes
9

After finding this thread again I have added it to the roadmap

https://tosdr.atlassian.net/browse/ROAD-31

2 Likes
10

The feature has been shipped and will be deployed into production next week ROAD-31 transliterate slugs now and revert back to ID if transliteration failed by JustinBack · Pull Request #1081 · tosdr/edit.tosdr.org · GitHub

2 Likes