On 21/09/10 18:57 +0200, Mathias Behrle wrote: > * Betr.: " Re: [tryton-dev] Improvement in language management" (Tue, 21 Sep > 2010 16:51:48 +0200): > > > On 21/09/10 16:48 +0200, Mathias Behrle wrote: > > > Don't know, if you got me right. Language (including date format etc.) is > > > just a choice of display in the client (same content, but different > > > display > > > of data). So no difference between language and date in this respect. > > > > No. Look at your computer, you can change the date format without changing > > the > > date. > > Exactly my words: > > same content, but different display of data > > > > Additionaly: > > > If there is a company that puts a policy to have the client used in one > > > specific language, I doubt it wants to allow the display of the date > > > format in user cutomization. At least it is absolutely unlogic. > > > > Why not? Why user should use the standard date format? I know many people > > that > > doesn't like the standard format fo their language. > > Why a user shouldn't use his preferred localization? Why should a company > impose retrictions on the usage of the client language? I know many people > that > don't like to work on an english localization. But if a company imposes such > policy, why OTOH should they allow for date formatting (and be it only for > display)? > > BTW: It seems that can already be acheived the different display in the client > by just creating another language with different date format. AFAIS it is only > used in the client, not in the docs. > > JFTR: I am playing here a little bit the 'advocat of the devil'. Usually > proposals like this get a link from you to a video showing a talk about the > problems arising from having too much choice;) > Finally no objection from me for the possibility of client customization.
You are right. This could be achieve by an external module.
But in fact, I saw many people asking about that on OpenERP so I guess it
doesn't require too much code (I guess <10 lines) to have this functionnality.
>
> > > > It is a developper choice to define which fields are translatable and it
> > > > is a company choice to define in which languages.
> > >
> > > Which sense does it make to restrict a company from the choice, which
> > > fields
> > > they want to have translated at all (and to impose it solely on the
> > > developer, who never will know about the specific demands of different
> > > enterprises)?
> >
> > Because making a field translatable has impact on how the code is written,
> > how
> > the database is performant etc. This is clearly a design choice!
>
> Changing design decisions (e.g. by extending modules) always affords the
> knowledge of the consequences and is always in the responsibility of the
> operator. Applies for devs as well as for admins.
I think you did not understand this issue. Per example:
There is a Tryton installation with Dutch, French and German activated
(Belgium :-). But the company doesn't want to manage the translation of
his product name in German because the market is too small.
So the admin of Tryton will set to German language that the name of the
product should not be translated into German but it will be for Dutch and
French.
This behavior is not possible for now in Tryton. And it is clearly a
configuration stuff.
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
pgpBW8J53rzCR.pgp
Description: PGP signature
