Merge lp:~numerigraphe/openobject-addons/trunk-stock-not-yet-invoiced into lp:openobject-addons
Proposed by
Numérigraphe
Status: | Rejected | ||||
---|---|---|---|---|---|
Rejected by: | Olivier Dony (Odoo) | ||||
Proposed branch: | lp:~numerigraphe/openobject-addons/trunk-stock-not-yet-invoiced | ||||
Merge into: | lp:openobject-addons | ||||
Diff against target: |
103 lines (+10/-10) 7 files modified
stock/i18n/fr.po (+2/-2) stock/i18n/stock.pot (+1/-1) stock/stock.py (+1/-1) stock_invoice_directly/wizard/stock_invoice.py (+1/-1) stock_location/i18n/fr.po (+2/-2) stock_location/i18n/stock_location.pot (+1/-1) stock_location/stock_location.py (+2/-2) |
||||
To merge this branch: | bzr merge lp:~numerigraphe/openobject-addons/trunk-stock-not-yet-invoiced | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Olivier Dony (Odoo) | Disapprove | ||
OpenERP Localization Experts | Pending | ||
Review via email: mp+82535@code.launchpad.net |
Description of the change
Makes the wording clearer for stock moves not yet invoiced.
I have changed the translation templates and the translations into French, and willingly left the other translations unchanged so that translators have a chance to catch up.
To post a comment you must log in.
Hi Lionel,
After reading the bug report I understand your concern, and I agree that "not yet invoiced" conveys almost the same meaning as "to be invoiced". However, I'm concerned by the fact that this is one of the possible values for the "Invoice Control" field, which are:
- Not Applicable
- To Be Invoiced
- Invoiced
Here "To Be Invoiced" really means: invoicing control is enabled for this picking, and the picking will need to be invoiced. In this context "Not yet invoiced" is weaker and does not stress the fact that it is a required step: it could even be confused with the "Not Applicable" case... Is it "not yet invoiced" because it will never be, because it is optional, or because someone will do it later?
In addition to this, it requires a `hard` change of translations in order to carry its full effect (as you noted), forcing every language to re-translate several terms.
To sum up, I think this is one case (like many others) where the users need to be trained to used the software properly, and trying to adapt it too much to one kind of user will impact others negatively.
Unless we see a very strong demand for this I'd prefer to keep it as it is.
If you really want to customize it for your users there are still many options: you can always provide you own fr.po translation file (or use your own fr_XX.po sub-language) and change the label of the state or that of the column, or even hide the column completely when it is confusing them.
I hope you'll understand this point of view..
Thanks for the merge proposal nevertheless, it's always a pleasure to review your contributions!