* Betr.: " Re: [tryton-dev] Improvement in language management" (Tue, 21 Sep 2010 13:40:30 +0200):
> 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.
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.
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.
> > > > > - 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.
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)?
--
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
