* 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).
> > 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 remember painful discussions about options like 'Show statusbar', 'Show
menubar', 'Change accelerators', ...
> I think this change is quiet simple.
Which is not the point.
> > > - 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.
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://mbsolutions.selfip.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
