domain.com/slug instead of domain.com/en/slug

[johnclause]

It is a common suggestion from a number of uses to make URL look like domain.com/slug instead of domain.com/en/slug, since 'slug' already defines the language. What is your insight on this?

[LC43]

Hi @johnclause, thanks for asking.Its one of the features that i always use. and i got mixed reactions when a client tried the recent qtranslate family. I ended using multiple installations.

[johnclause]

Hi Pedro (@LC43), I am a bit confused what you mean here. Can you explain a bit more what exactly feature do you mean in "Its one of the features that i always use"? I might made my question too short. I did not mean any feature which can be used or not used. The -slug plugin currently works by replacing standard slug with a language specific one in the URL like this domain.com/en/slug. What people ask, is why do we need to keep '/en' there, since new language specific slug already defines the language uniquely and '/en' becomes redundant. So they want to see domain.com/slug instead, which indeed makes sense, but I am afraid it would require a lot of changes in the code to implement it. It might be even easier to make a new plugin instead. Have you ever thought about redundancy of language tag like '/en' in the URL with language specific slug?

[LC43]

Ohhh! I thought you meant to either keep / or /lang for the default language.

We make sure each slug is unique in its domain. It would mean it now would be unique in all languages, taxonomies ( if the user disabled /category/ ) and attachments ( there's a bug report from a user that had a file with the same name as the post and it was causing him 404).

Now that would be awesome!!

It would have to take care of home page too: Default lang: / 2nd lang : /homepage-slug-in-2ndlang/

On Tuesday, February 10, 2015, johnclause [email protected] wrote:

Hi Pedro (@LC43 https://github.com/LC43), I am a bit confused what you mean here. Can you explain a bit more what exactly feature do you mean in "Its one of the features that i always use"? I might made my question too short. I did not mean any feature which can be used or not used. The -slug plugin currently works by replacing standard slug with a language specific one in the URL like this domain.com/en/slug. What people ask, is why do we need to keep '/en' there, since new language specific slug already defines the language uniquely and '/en' becomes redundant. So they want to see domain.com/slug instead, which indeed makes sense, but I am afraid it would require a lot of changes in the code to implement it. It might be even easier to make a new plugin instead. Have you ever thought about redundancy of language tag like '/en' in the URL with language specific slug?

— Reply to this email directly or view it on GitHub https://github.com/not-only-code/qtranslate-slug/issues/103#issuecomment-73765426 .

[johnclause]

Hi Pedro,

Would you wish to cooperate to implement it? I believe we can introduce a new URL modification mode 'Slug' in addition to 'Pre-Path', 'Pre-Domain', and 'Query'. I have already put filters/actions in some places where I think they would be needed to implement it. For example, there is apply_filters('qtranslate_parse_language_info_url_mode' in function qtranxf_parse_language_info, where Slug mode would fall in. There is also do_action('qtranslate_url_mode_choices') in configuration file, where you can add new mode to the list of choices. Other hook you will need inside convertURL function. Do you think it makes sense?

Do you wish to get engaged on this kind of change? I will cooperate on filters and hooks you need. I would not advise you to override the whole function some place, although I made it possible with if(function_exists, since it will complicate the maintenance. If you need to change functionality, let me know and we will figure out the best mutually supportive way.

Best wishes, John

[LC43]

Hi @johnclause, i would love to work on this. But i'm overwhelmed at my job right now and i'm moving to another country in a few days, so i'm not even sure when i can have a break during the next few months.

sorry :(

[johnclause]

Ok, then this can wait for now. I have some other fires to fix first too. Let us keep it open and we will come back to it later.

[LC43]

@johnclause how is your slug implementation? i'm planning to review the slug creating for 1.1.19.

the next version fixes categories and merges github and wp.org codes.