The french translation for UoS is misleading

Bug #400702 reported by Numérigraphe
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
Nominated for 5.0 by Numérigraphe

Bug Description

For the locale fr_FR, the term UoS ("unit of sale") was translated to US ("unité secondaire" = "secondary unit"), which is misleading for the users. They might think the software operates the opposite way.
I changed the translation on Launchpad on the 5.0 branch and on the trunk in the following modules : product, sale, mrp, account, purchase, delivery, auction, hr-timesheet, stock.
Could you please update the PO files in the 5.0 branch ?
Thanks in advance!

(Edit: Originally I thought UoS was for Unit of Stock but it was a mistake.)

Tags: 5.0
Revision history for this message
Christophe CHAUVET (christophe-chauvet) wrote :


The UoS is not "Unit of Stock", but "Secondary unit"
and UoM is "Master Unit".

The secondary unit must be a different category from Master
ex: UoM is Kg and UoS is PCE (useful in food industry)


Revision history for this message
Numérigraphe (numerigraphe) wrote :

I checking the docs and I made a little testing in v5 and UoS seems to be for Sale indeed, and UoM for stock.
I'm not too keen on keeping "primaire/secondaire" because :
- it's not the English wording : the English should be changed first so all translators benefit from it
- it gives users less indication of what it is for.
I'm changing the French translation for UoS to "UdV" on the trunk. I'll suggest it for v5 and let you review.

Revision history for this message
Numérigraphe (numerigraphe) wrote :

For consistency, I changed to "UdV" everywhere in the 5.0 series and added back the suggestions for "primaire/secondaire" so Christophe can chose the one he likes best for the stable release.

Christophe: Is "UdV" ok with you for 5.0 ?
If you change back to "primaire/secondaire", would you please do so for every template for consistency ?


Revision history for this message
Christophe CHAUVET (christophe-chauvet) wrote :


> Christophe: Is "UdV" ok with you for 5.0 ?

No, because is not only for sale, it can be used to purchase or stock process.

This permit to work with 2 Units whom are in different categories

Fabien, can you confirm this ?

Changed in openobject-addons:
assignee: nobody → Fabien (Open ERP) (fp-tinyerp)
Revision history for this message
ssi (Open ERP) (ssi) wrote :

IMHO to maintain consistency lets keep "Unit of Sale" as "unité de vente".
I agree that it works as secondary unit but here functionally the case is bit diffrent.When we are purchasing in diffrent unit and we wish to sell in diffrent then at that time UOS comes in picture.
for eg If we are purchasing in "kgs" and wish to sell in "grams",then UOS i.e grams can't be treated as secondary unit.It might create misconception in the mind of Enduser.

Instead we can change in help text
en: "Used by companies that manages two unit of measure: Invoicing and Stock management. For example, If we are purchasing in "kgs" and wish to sell in "grams",then UOS will be "Grams" and UOM as "KGS" else Keep UOS empty to use the default UOM"

fr: "Utilisé par des entreprises qui gère deux unités de mesure: de facturation et de gestion de stock. Par exemple, si nous sommes dans l'achat de " kg " et qui souhaitent vendre en" g ", puis UOS sera
" Grams " et UOM comme " KGS " else Gardez UOS vide pour utiliser la valeur par défaut UOM"

Revision history for this message
Numérigraphe (numerigraphe) wrote :

SSI, I quite agree with that. Would you object to the use of the shorter form "UdV" in the french translation ?

BTW Phuong of Tiny just changed back the translations for UOS on v5.0 (not yet on the trunk BTW) to "US" and "Unité secondaire".
Phuong: do you mind if I change to "UdV" and "Unité de vente" ?

description: updated
Revision history for this message
Phuong (phu) wrote :


I had a discussion with Fabien about this topic in order to clarify things for everyone and keep consistancy in Open ERP. He's opinion is to keep:

EN: UoM = Unit of measure / FR: UdM = Unité de mesure
EN: UoS = Unit of sale / FR: US = Unité secondaire

On the product form, you'll see that all fields concerning UoS are grouped under the title "Second UoM", means "Unité de mesure secondaire".

So, even though in english version we talk about "Unit of sale", you have to think in terms of "Unit of measure" (by default), and "Second unit of measure" (for companies that used to manage different CATEGORIES of units for a same product, for example Pieces and Kgs).

Talking about "Unité de vente" is wrong because people will use this field even if they actually use different units from a same category (like Kg and Grams) while it should be used for different units from different category.

So to resume, maybe we should change all english terms "UoS" or "Unit of sale" into "SU" or "Secondary unit"...

I hope these explanations will clarify this problem for you...

Revision history for this message
Numérigraphe (numerigraphe) wrote :

Phuong, thanks for taking time to discuss it with Fabien and answering.
I have no problem with this wordng as long as it is made consistent all over OpenERP.
That means :
- the French translation must be "US" in every place (I can verify this on v5.0 if you wish).
- the english wording has to be changed everywhere in the trunk from "Unit of Sale" to "Secondary Unit"
- the translations in every language has to be fixed on the trunk to reflect the former change

Revision history for this message
Numérigraphe (numerigraphe) wrote :

I registered a blueprint so hopefully the English wording is changed on the next version.

Changed in openobject-addons:
assignee: Fabien (Open ERP) (fp-tinyerp) → nobody
status: New → Fix Released
Revision history for this message
Ana Juaristi Olalde (ajuaristio) wrote :

No please. Don't change it. As I could see, the secondary unit is not secondary unit but only means you can sell the product on different category secondary unit. If it's not like that I'm missing something important.

Secondary unit should mind the possibility of controlling stocks on 2 different stock units. Not only for sale or purchase but for controlling stock himself.

Raphaël Valyi is building the extra module for a customer of mine to controll this. There is a lot of industries where this functionality is required (wood where they need having controlled units and m2, iron units and m, foundry m and kg, fish selling units and kg ) We will publish module nearly next week.

You can see the blueprint here:

So, if you change UOS to secondary unit, confusion will increase more than now is. But It's my oppinion.

Revision history for this message
Derek Simkowiak (ubuntu-cool-st) wrote :

In deciding how to name my "unit of measure" fields in my own ERP app, I googled some other apps, to see how they do it.

SAP has a "Base Unit Of Measurement", and allows for customized UOMs for orders, production, etc:

Adempiere has a wiki discussion page on this topic:

They discuss a Bill Of Materials UOM as the base "standard", and then "Stocked UOM", "Price UOM", "Storage UOM", etc. Basically, in the Wiki discussion they allow for a custom UOM for any kind of stock movement or account change, similar to SAP.

And re: Phuong on 2009-09-18: "Unit of Measure" and "Unit of Sale" seems arbitrary. What about "Unit of Production"? "Unit of Storage" / "Unit of Stock"? "Unit of Transfer"? Those might be different from both the base UOMeasure and the UOSale.

Note that the common term SKU is a "Stock Keeping Unit", and refers to a specific Product in a specific Unit Of Measure.

It seems to me that just two UOMs: "Master Unit" and "Secondary Unit" is not sufficient... especially if they are named "Unit of Measure" and "Unit of Sale"...

There is a terrific list of ERP terms in English here:

I highly recommend that entire website for any ERP questions. The author is domain knowledge expert in inventory management, and he writes as if he's a programmer.

Revision history for this message
Nhomar - Vauxoo (nhomar) wrote : Re: [Bug 400702] Re: The french translation for UoS is misleading


Totally agree with Derek..... But.........................

Totally agree with Ana too!!!!!!!!!!!!!! this blueprint _must_ be
implmented, but in V6.... because the behaviour in almost all modules
related with stock will need refactoring..... This must be be checked in
depth first... before pull to trunk......


To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.