Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
WinDev Forum
Beiträge im Thema:
11
Erster Beitrag:
vor 6 Jahren, 11 Monaten
Letzter Beitrag:
vor 6 Jahren, 11 Monaten
Beteiligte Autoren:
RAUL, Peter H., Tomas

[WD] Multi-language fields?

Startbeitrag von RAUL am 10.08.2011 14:13

Hello guys.

I need to solve this issue and wanted your advise please.

I have a multi-lang app. Everything works find with Nation() for changing lang at run-time. But this particular app needs that the data inserted into table fields to be multi-lang too.

For example:


Window "Categories"
Description: ___STEAK HOUSES____
Hint:_________________________________________________



When I translate the win with Nation():


Ventana "Categorías"
Descripción: ___STEAK HOUSES____

Antworten:

Hola Raul,

So you need some of the fields to be with multilingual content ?

Perhaps you could create subscripted fields for each language in your analysis : RESTTYPE[1]=steakhouse-(engl);RESTTYPE[2]=parrillada-(span);RESTTYPE[1]=steakhaus-(ger)

You would call the corresponding data based on Nation & extract the related subscripted field.

Saludos,
Tomas

von Tomas - am 10.08.2011 17:54
Hi Tomas,

Although this might be a good idea I would not recommend it since it will bind you to HF (and maybe some other) databases only. Only a few db engines provide this sort of cuntionality and there is no standardisation on this feature.

The correct way would be to create a second table with a foreign key (normalization) which can hold n number of descriptions in the different languages for a given entity. Use a default description in the main file.

For displaying purposes, just use a query joining both tables.
select a.resttypeid,
(CASE WHEN b.resttype is not NULL then b.resttype ELSE a.resttype END) as resttype
from resttype a
left outer join resttypelanguage b on a.resttypeid = b.resttypeid and b.resttypelang = userlanguage

Just my 2 cents...

Cheers,

Peter

von Peter H. - am 11.08.2011 08:26
Hello guys.

Many thanks for your replies!

I actually didn't know about subscripted fields in HF! It could be an interesting approuch.

What Peter suggested is useful too. Now, in your opinion, if I never switch to another DBMS, do you think that the best solution is Tomas' approuch?

Kind regards.

PS: hola Tomás, no hay mucha gente de habla hispana en el foro, vos de dónde sos? Hace tiempo que estás con WD?

von RAUL - am 11.08.2011 16:18
Hi Raul,

I've never used 'arrayed' fields so I cannot provide a suggestion based on experience. There might be one caveat though: having an open type of search on it using queries. I don't know how that works in W-Language and how flexible it is. If it is easily implementable it might be a good choice if you never intend to switch db's (Although I had to do a 'never intended switch' to SQL Server because of performance issues with HFCS on complex joins and the lack of persistent (materialised or indexed) views).

My solution is defintely easily searchable for all type of text queries (begins/contains/ends/...).

Cheers,

P.

PS: I also believe there are a few limitations when using 'arrayed' fields in WX. Well, that is based on when I looked at it in the old 5.5 days more than a decade ago so it might be irrelevant now...

von Peter H. - am 11.08.2011 17:57
Peter. Thank you very much for your suggestion. I have to agree that your method is -definitively- stronger that the subscripted fields.

I guess I'll have to do some try and error on both in order to make a desicion. Of course, if someone have any other possible approach, it's very wellcome.

Regards.

von RAUL - am 11.08.2011 18:40
Hola Raul,

You may have to try both approaches...as for the "arrayed" files I find them practical for certain purposes such as yours where you can organize same types of data which are repetitive & could be easily found via indirection+integers; also,this works in the query builder,etc. only drawback I found so far is that when you look at your livedata you can get easily lost within the many columns of data being displayed all with the same heading...this should be improved !

Good luck & let us know your chosen path..

P.S. : Estoy del otro extremo del continente en Venezuela...desde WD8 !

von Tomas - am 11.08.2011 19:37
Hi all.

I think that "arrayed" fields won't solve this issue 'cause it's impossible to index them.

Maybe I should simplify this by issuing a fixed amount of languages. If I have 4 fixed langs, then I can define one field for each multi-lang item. For example:

- ID int // this field won't be translated.
- Name1 string // for lang 1 and so on...
- Name2 string
- Name3 string
- Name4 string

I think this is the way I'll choose to go.

von RAUL - am 16.08.2011 14:48
Hi Raul,

This is also an option, but it may cause a lot of additional coding in dynamically displaying the right column in windows, pages and reports depending on the users language. It will make multi-lingual searches also a less straight forward. You might have a look again on my normalised design pattern which is a generally accepted best practice design method. Searches can be done on all languages at once if you want and the result will always come back as a single column that can be bound to the same control no matter the language. The only additional coding needs to be done at the maintenance level of the entity (parent-child).

Just my 2 cents.

Regards,

Peter

von Peter H. - am 16.08.2011 20:51
Hi Raul,

This is also an option, but it may cause a lot of additional coding in dynamically displaying the right column in windows, pages and reports depending on the users language. It will make multilanguage searches also less straight forward. You might have a look again on the normalised design pattern which is a generally accepted best practice design method. Searches can be done on all languages at once if you want and the result will always return as a single column that can be bound to the same control no matter the language. The only additional coding needs to be done at the maintenance level of the entity.

Just my 2 cents.

Regards,

Peter

von Peter H. - am 16.08.2011 20:52
Hi Peter. You're right, a lot of additional coding have to be done. Maybe it's better to make 2 simple tests and compare both approaches.

Thanks a lot for your advise and your time.

von RAUL - am 17.08.2011 14:36
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.