On 21/09/10 12:35 +0200, Mathias Behrle wrote: > * Betr.: " Re: [tryton-dev] Improvement in language management" (Tue, 21 Sep > 2010 11:52:42 +0200): > > > On 21/09/10 11:45 +0200, Mathias Behrle wrote: > > > * Betr.: " [tryton-dev] Improvement in language management" (Mon, 20 Sep > > > 2010 20:21:30 +0200): > > > > > > Hi, > > > > > > > We got some discuss about possible improvement in the language > > > > management. > > > > Here are the issue and possible solution: > > > > > > > > - The date format (and number format) is linked to the language. But > > > > sometimes users would prefer an other one. Per example if you are a > > > > french guy and you must work with Tryton in English (corporate policy), > > > > you will find annoying to use the english date format. > > > > > > > > Allow to define a custom date format (and number format) on user > > > > preferences > > > > (in the client interface) and use it for the client display. > > > > Reports or any things else will still use the default date format > > > > defined on the language. > > > > > > If it is corporate policy to work in foreign language, date and number > > > format belong to it. It could even be corporate policy to not *allow* the > > > user to change any display format. > > > > Company doesn't care the way you use to encode date. As I said, it is only > > for > > the client display. > > Same argument applies to language: it is just the display in the client. So > company seems to care in some cases (whether it makes sense or not).
False, the language formating is used in reports. > > > > - You could have activated many languages in Tryton because you have a > > > > lot of different users languages. But per example the company doesn't > > > > want to maintain a translation for all languages of the product name (or > > > > any other translatable fields). > > > > > > > > Allow to define on the languages a list of fields to exclude of the > > > > translation. This will be taken by the client and it will not propose > > > > to > > > > translate the field for these languages. > > > > The current default behavior will be keep in case of reading a record > > > > with a language that is not translated which is to give the english > > > > version. > > > > > > Do I miss something in saying, that a company could remove the translate > > > attribute from a field, if it doesn't want to be the field translatable? > > > > It is to remove some languages from the translate popup. > > > > > But it could be indeed an interesting feature, if it would also work the > > > other way: Define fields to be translatable in the client. This way the > > > translatable attribute just would be default, that could be entirely > > > customized. > > > > This is not a good thing because making a field translatable is a design > > (developper) choice. > > Sorry, citing you: > > > > But per example the company doesn't > > > > want to maintain a translation for all languages of the product name (or > > > > any other translatable fields). > > So is it developper or company choice? I am sticking to my proposal to let the > developper make the defaults (proposals, that he estimates to be applicable) > and to let decide the company which one is required. It is a developper choice to define which fields are translatable and it is a company choice to define in which languages. -- 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/
pgpc3sFnZv1aS.pgp
Description: PGP signature
