Prestashop: Translate carrier name

[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.

[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

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,

[matks]

@marionf @samuel-pires we're implementing this in https://github.com/PrestaShop/PrestaShop/pull/14551

How should the shop behave when upgrading ?
Before 1.7.7 : carrier name is global, not translatable so it's the same for every lang
After 1.7.7 : carrier name can be customized for each language

For a shop which has "french" has default language, should we keep the carrier name for French only and leave other languages empty ?
Or should we set the previous carrier name as the value for every languages of the shop, and the shop admin will be able to modify it later ?

[VorobiovM]

@matks setting the value for every language will avoid unnecessary problems and will not disturb customers from choosing a carrier in the time period when admin modifies a translation.

[sarjon]

we're implementing this in #14551

@matks now I think that we should do it in a separate PR. This is kind of new feature and it can potentially affect both FO and BO, especially when there are plain sql queries selecting name directly from carrier table instead of carrier_lang.

That way, we can validate Carrier migration much faster and then focus on this new feature, wdyt?

[matks]

👍 @sarjon

[PrestaShark]

Up!

[LouiseBonnard]

Hi @marionf, you are mentioned in conversations related to this issue, cf. PR https://github.com/PrestaShop/PrestaShop/pull/14551 & https://github.com/PrestaShop/PrestaShop/pull/15360. It looks like the decision has been made not to make carrier names translatable for PrestaShop 1.7.7, what about version 1.7.8? I guess the pros and cons are still the same.

[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