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. > I am in doubt, whether this feature is of any use. If I take into account, how > difficult it is and was to get other customization features into the client I > am wondering that you even think about this feature. I don't understand. Which features are you talking about? I think this change is quiet simple. > > - 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. -- 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/
pgpgmMAF3ZeMb.pgp
Description: PGP signature
