Make carrier name multilingual

[VorobiovM]

Is your feature request related to a problem? Please describe.
Many Prestashop e-commerce's uses local carriers, that may have different names depending on the language.

Describe the solution you'd like
Add the ability to localize courier name. This feature was first proposed by [PSCSX-8505] back in 2016.

Here are the specs for the localization.

Specs

Page: Shipping > Carriers > Add new / edit carrier

[US]: As a user, I want to be able to localize a carrier name so that I can adapt it to different languages

Solution

Add a dropdown menu to the "Carrier name" field in order to select the language.

[khouloudbelguith]

Hi @VorobiovM,

Thanks for your suggestion.
Yes, it could be a good improvement to have a carrier name in Back Office is translatable Multilanguage

@marionf, @colinegin what do you think?
Thanks!

Previous ticket on forge: http://forge.prestashop.com/browse/BOOM-4699

[ghost]

Hi @VorobiovM,

Thanks for you feedback 👍

Just to be sure, what you would like is to have is a dropdown menu on the "Carrier name" line with your different localizations?
Like in the picture below :

[VorobiovM]

Hi @Samuel-Pires,

Yes, a dropdown will be perfect.

[rdy4ever]

I'm in on this too. Sometimes, you don't want to disclose the carrier name, and you would preffer to be something like "Express delivery" - that needs to be translated.
Also - the "Pick-up in store" delivery method needs to be translated.

[ghost]

Thank you both for your feedback. We'll look into it !
Do not hesitate if you have more info about this feature.

It is always good for us to know how you use a feature and in which context 👍

[ghost]

@rdy4ever, when you say "Pick-up in store" delivery method has to be translated, are you talking about the "transit time" field? (see image)
It automatically adapts to the shop's language, though it might be not translated in in all languages yet (see Crowdin https://crowdin.com/project/prestashop-official)

[rdy4ever]

@rdy4ever, when you say "Pick-up in store" delivery method has to be translated, are you talking about the "transit time" field? (see image)
It automatically adapts to the shop's language, though it might be not translated in in all languages yet (see Crowdin https://crowdin.com/project/prestashop-official)

Yes. But wouldn't it be better if "Pick-up in store" would be the name of the carrier (shipping method)?

[ghost]

Makes sense, we'll look into it.

[ghost]

Here are the specs for the localization.

Specs

Page: Shipping > Carriers > Add new / edit carrier

[US]: As a user, I want to be able to localize a carrier name so that I can adapt it to different languages

Solution

Add a dropdown menu to the "Carrier name" field in order to select the language.

[ghost]

@matks I add this issue in the Shipping > Carriers > Add new / edit carrier page migration EPIC. Feasibility is ok?

[ghost]

@rdy4ever, when you say "Pick-up in store" delivery method has to be translated, are you talking about the "transit time" field? (see image)
It automatically adapts to the shop's language, though it might be not translated in in all languages yet (see Crowdin https://crowdin.com/project/prestashop-official)

Yes. But wouldn't it be better if "Pick-up in store" would be the name of the carrier (shipping method)?

Hello @rdy4ever,
I created another issue to modify the default Name and Transit Time: #13828

Best,

[marionf]

Yes, the advantage is if we do it soon (at the start of version 1.7.8), we will be able to inform the module developers that all modules that change the names of carriers must upgrade their logic because a text field and a translatable text field can't be handed in the same way.

[matks]

@marionf Are you sure you want to do this ?

If we implement this in the current way it's aiming, we will switch from a single-field name to a multi-field name (one field per language). This is a huge BC break which means "it is unlikely that a module that does not modify its code does not break".

Let's imagine that there are 1000 PrestaShop shipping modules in the world.
If they do nothing, upon release of 1.7.8.0 we have 0/1000 shipping modules compatible with PS 1.7.8 . No UPS, no DPD, no La Poste.

We can expect a portion A of these modules to upgrade, and a portion B to do nothing. What do you think will be A ? 10% ? 20% ? 50% ?

Even if A is 50% that means there are still 500/1000 modules that will not be possible to install on a PS 1.7.8 .

Overtime we can expect A to grow and B to reduce. But how long ? And B will never reach zero. A is "PS 1.7.8 compatible modules" and B is "PS 1.7.8 not compatible modules".

So this is a huge price to pay. What about the benefits ? Well, we aim to pay this huge price in terms of compatibility and interchangeability between systems ... to be able to translate Carrier names.

This is where I feel weird 😅 . I mean ... if it was to enable multi-carrier shipping, right, that is a feature worth money and worth the bother. Or enable, I dont know, 1-click order. Or enable ... automatically updated shipping details ? What a nice feature.

But translatable carrier name 😅 ..? is that tiny little feature (that is useful nonetheless) really worth breaking almost all shipping modules for 1.7.8 and hoping module developers diligently upgrade their code ?

So my thoughts here are:

1. I suggest considering to post-pone this for PrestaShop 8.0.0 where there will be similar huge breaking changes, meaning people will be obliged to update their code

2. Or work on a way to preserve some backward compatibility (like a Feature Toggle). This way on the release day we might not have A = 0% but rather 50% or 60% without the need for modules to upgrade.

[marionf]

This is a huge BC break which means "it is unlikely that a module that does not modify its code does not break"
If they do nothing, upon release of 1.7.8.0 we have 0/1000 shipping modules compatible with PS 1.7.8 . No UPS, no DPD, no La Poste.

I didn't know all modules were concerned, I thought it was only a few

We can expect a portion A of these modules to upgrade, and a portion B to do nothing.

It's the same problem if we do that for (1).8.0, we can prevent them but we can't be sure they will update their code.

I suggest considering to post-pone this for PrestaShop 8.0.0 where there will be similar huge breaking changes, meaning people will be obliged to update their code

You're right, it's a little feature with not much benefit, so if it impact 100% of the modules, I am ok to postpone it for (1).8.0

[hibatallahAouadni]

Ping @PrestaShop/product-team what's the status of this issue?

[lmeyer1]

I don't agree with the analysis of @matks. Translating the carrier name is not such a breaking change that it will break all carrier modules.

I'm working on an implementation for our shops. As far as I can determine, there are three things to do:

• In the database, add the name field to the table _carrier_lang like this, $carrier->name will become an array
• Everywhere when $carrier->name is passed to smarty, replace it with is_array($carrier->name) ? $carrier->name[$order->id_lang] : $carrier->name or similar. I found until now about 10 occurrences. This will keep the compatibility with a database not set up for translation.
• We need to adapt the BO carrier form in Shipping - Carriers menu.

[matks]

@lmeyer1

Everywhere when $carrier->name is passed to smarty, replace it with is_array($carrier->name) ? $carrier->name[$order->id_lang] : $carrier->name or similar. I found until now about 10 occurrences. This will keep the compatibility with a database not set up for translation.

This will work only if modules rely on Smarty variables to fetch the carrier name.

Some modules gather data by querying the database directly. Example:

$sql = 'SELECT c.`id_carrier`, c.`name`
						FROM `' . _DB_PREFIX_ . 'carrier` c
						LEFT JOIN `' . _DB_PREFIX_ . 'carrier_zone` cz ON (cz.`id_carrier` = c.`id_carrier`)
						LEFT JOIN `' . _DB_PREFIX_ . 'zone` z ON (z.`id_zone` = ' . (int) $id_zone . ')
						WHERE c.`id_carrier` = ' . (int) $id_carrier . '
						AND c.`deleted` = 0
						AND c.`active` = 1
						AND cz.`id_zone` = ' . (int) $id_zone . '
						AND z.`active` = 1';

Other modules will fetch the Carrier ObjectModel and call $carrier->name expecting a string, but what will be returned is an array.

Because until now, PrestaShop never defined a standard way to retrieve PrestaShop data, modules do whatever they want, and retrieve data the way they want. That is a big constraint that prevents us from doing a lot of needed refactoring.

On your shops, you control what modules are installed. You control what fetches carrier names, so you can do this change 😄 but the Core is made available to the 300,000 shops powered by PrestaShop, and we have no control on what modules or themes are plugged on these shops.

[lmeyer1]

Thanks @matks for your explanation. I understand now why this feature would not be part of the core.

I think about creating nevertheless a pull request once I'm done. This could help others that are interested int his feature. As this thread shows, there are some.

[matks]

I think about creating nevertheless a pull request once I'm done. This could help others that are interested int his feature. As this thread shows, there are some.

That would be very nice and this is 100% the open source spirit 🎉 thank you !

[tswfi]

What about adding a new "Name for customers" field that can be translated and used in templates.

Templates could even do something like $carrier->getTranslatedNameOrName() that returns the translated version if it exists or the original "name" field.

This would keep backwards compatibility but allow doing the translations.

(this idea stolen from another system that I have worked on. Every object had "Alias" which is unique and "Name" that is translatebale and everyobject has a $object->getNameOrAlias() method. The aliases were really useful with integrations also, kinda like product reference in prestashop).

[d33x]

Translating the name of the carrier is a good thing, but what if the carrier uses two different names for the same language?

Let me take a simple example with DPD. In France (French language), it is usually the Chronopost service that is used. In Belgium (French language too), it is DPD. Same carrier but different name depending on the country (and not necessarily the language)

[lmeyer1]

You can limit carriers to countries. Thus in your case, create two carriers, on for France and one for Belgium. I think this should not be a problem.

[d33x]

You are right, except when you use the module of a carrier and that this one authorizes only one carrier (in particular for the generation of label or the follow-up)