Replies: 30 comments
-
Hi @VorobiovM, Thanks for your suggestion. Previous ticket on forge: http://forge.prestashop.com/browse/BOOM-4699 |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
Hi @Samuel-Pires, Yes, a dropdown will be perfect. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Thank you both for your feedback. We'll look into it ! It is always good for us to know how you use a feature and in which context 👍 |
Beta Was this translation helpful? Give feedback.
-
@rdy4ever, when you say "Pick-up in store" delivery method has to be translated, are you talking about the "transit time" field? (see image) |
Beta Was this translation helpful? Give feedback.
-
Yes. But wouldn't it be better if "Pick-up in store" would be the name of the carrier (shipping method)? |
Beta Was this translation helpful? Give feedback.
-
Makes sense, we'll look into it. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
@matks I add this issue in the Shipping > Carriers > Add new / edit carrier page migration EPIC. Feasibility is ok? |
Beta Was this translation helpful? Give feedback.
-
Hello @rdy4ever, Best, |
Beta Was this translation helpful? Give feedback.
-
@marionf @Samuel-Pires we're implementing this in #14551 How should the shop behave when upgrading ? For a shop which has "french" has default language, should we keep the carrier name for French only and leave other languages empty ? |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
@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 That way, we can validate Carrier migration much faster and then focus on this new feature, wdyt? |
Beta Was this translation helpful? Give feedback.
-
👍 @sarjon |
Beta Was this translation helpful? Give feedback.
-
Hi @marionf, you are mentioned in conversations related to this issue, cf. PR #14551 & #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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
@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. 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:
|
Beta Was this translation helpful? Give feedback.
-
I didn't know all modules were concerned, I thought it was only a few
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.
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 |
Beta Was this translation helpful? Give feedback.
-
Ping @PrestaShop/product-team what's the status of this issue? |
Beta Was this translation helpful? Give feedback.
-
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:
|
Beta Was this translation helpful? Give feedback.
-
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:
Other modules will fetch the 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
That would be very nice and this is 100% the open source spirit 🎉 thank you ! |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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) |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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) |
Beta Was this translation helpful? Give feedback.
-
I found this, is not the best solution but it works, the thread is in spanish:
} changeCarriersNames();` |
Beta Was this translation helpful? Give feedback.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions