search

yktoo / dklang

DKLang Localization Package
56 stars 14 forks source link

DefaultLanguageID should be published #4

Closed WarmBooter closed 10 years ago

WarmBooter commented 10 years ago

Not all projects are written with interface in US English. My suggestion is that the DefaultLanguageID should be a published property.

Also, in spite of the fact that actually I can set the DefaultLanguageID to something different from the US_EN in the form.oncreate, doing so causes side-effects when you try to change the language in runtime, ie: you need to change the language twice for the first time to actually take some effect in the application interface.

Update: To solve the problem mentioned in the second paragraph, it is needed to set the LanguageId property after changing the DefaultLanguageID in the form.oncreate.

bjmillerpa commented 10 years ago

TDKLanguageManager is not a component rather it is a static class that controls the current language for all of the language controllers on forms. Not being a component, publishing its properties does no good. The preferred way to set a language other than English as default would be to set the default language in your application's project source file before any forms are created. Also, if you are storing your "default" translation in a language file, then it's not the default. The default translation is whatever language is used for text in your form components stored in the form source, regardless of the language (or whatever DKLang thinks the language id of it is).

WarmBooter commented 10 years ago

I understand your worries, but actually you already have non-visual components available Anyway, setting the variables in the dpr seems to be ok.

yktoo commented 10 years ago

I agree with @bjmillerpa, publishing properties of a non-component doesn't add any value and only creates overhead.