Radicore Forum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » RADICORE » RADICORE Suggestions » Internationalisation suggestion
Internationalisation suggestion [message #1379] Mon, 30 June 2008 15:46 Go to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
What do you think about this suggestion?

In the column dictionary I would suggest adding a one to many relationship with a new table that had two fields: language_id and title_for_the_column_in_this_language.

When importing a table you could create a record with a default title (as you do now) for the default language.

Then, when you need to add a description for a new language you should come to the column dictionary and add the record to this new table.

I also think that the titles shouldn't be hardcoded in the .screen.inc files, couldn't the framework retrieve the titles from the dictionary? This way if you change a title for a table you shouldn't go file by file updating it.

Re: Internationalisation suggestion [message #1381 is a reply to message #1379] Mon, 30 June 2008 16:03 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
I do not use the data dictionary for internationalisation, instead I use a series of text files, one per language, in the 'text' subdirectory. I deliberately chose this method as a single text file can contain multiple entries whereas with the database option I would would require a separate read for each entry, and this would be much slower.

It is also easier to provide translations as all you have to do is give the translator a text file which he can modify instead of getting him to change the contents of the database.

It is possible to have translations for any piece of text - screen titles, column names, menu buttons, navigation buttons as well as error messages.

As my current method works very well I see no reason to change it.


Re: Internationalisation suggestion [message #1383 is a reply to message #1381] Mon, 30 June 2008 16:14 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
It's not about if it works or it doesn't I guess it's about improving radicore Smile

By using the data dictionary for labels you simplify the internationalisation, don't have to deal with files etc. Is much easier for an inexperienced user.
It's consistent as metadata is stored in the dictionary, not in a file. You can visually see tha labels without having to go to the files etc.
You could also have dictionary tables for the other things that are not related to tables.

Also having the .screen.inc files retrieving the labels from the dictionary would be great, I'm sure there is a way of caching the titles the first time you need them so there is no need to retrieve them every time.
Re: Internationalisation suggestion [message #1385 is a reply to message #1383] Mon, 30 June 2008 16:37 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
I do not consider you suggestion to be an improvement over the existing method, it is just different. I have worked with other systems in the past that used non-database files for all foreign language text, so I am not alone in thinking that is has merits.

Unless you can present a compelling reason why I should switch to a different method I see no reason to change anything.


Re: Internationalisation suggestion [message #1390 is a reply to message #1385] Tue, 01 July 2008 04:55 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
AJM wrote on Mon, 30 June 2008 16:37

I do not consider you suggestion to be an improvement over the existing method, it is just different. I have worked with other systems in the past that used non-database files for all foreign language text, so I am not alone in thinking that is has merits.

Unless you can present a compelling reason why I should switch to a different method I see no reason to change anything.


I've been working also with a big ERP (kind of SAP) and they had it done this way. There was a cache system where all the labels where stored the first time they where retrieved.

In this scenario: you have you application finished, full of transactions etc, now you client asks you to change the title of a column, as it is right now you should have to deal with a lot of files and I'm sure you will forget some. With my suggestion you just go to the dictionary, change the label and that's it.

As for other labels fr buttons etc create a table with "label_id, language_id, text" then a global function can be used wherever you want to retrieve a label for a given language.

You also avoid the hardcoding of titles in the screen.inc files.
Re: Internationalisation suggestion [message #1391 is a reply to message #1379] Tue, 01 July 2008 05:09 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
OTOH I believee radicore is about making web application easier, I believe that after creating tables etc, you should only need a web browser and an editor to create/maintain a web application.
I don't want to bother you more, but I belive my suggestion is easier to use, more flexible and it separates more the presentation layer from the data layer.
Re: Internationalisation suggestion [message #1394 is a reply to message #1390] Tue, 01 July 2008 05:29 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
Quote:

In this scenario: you have you application finished, full of transactions etc, now you client asks you to change the title of a column, as it is right now you should have to deal with a lot of files and I'm sure you will forget some. With my suggestion you just go to the dictionary, change the label and that's it.

If you have a separate entry in your database for each language then changing the label text for a column will still require a separate update for each language.

In my design each subsystem has a single text file for each language containing the text for everything - task titles, column labels, menu buttons, navigation buttons and error messages - so to change the label for a column still requires one update per language. There is no saving with your method.


Re: Internationalisation suggestion [message #1396 is a reply to message #1394] Tue, 01 July 2008 05:36 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
AJM wrote on Tue, 01 July 2008 05:29

Quote:

In this scenario: you have you application finished, full of transactions etc, now you client asks you to change the title of a column, as it is right now you should have to deal with a lot of files and I'm sure you will forget some. With my suggestion you just go to the dictionary, change the label and that's it.

If you have a separate entry in your database for each language then changing the label text for a column will still require a separate update for each language.

In my design each subsystem has a single text file for each language containing the text for everything - task titles, column labels, menu buttons, navigation buttons and error messages - so to change the label for a column still requires one update per language. There is no saving with your method.


I found myself wanting to change a label in a list1 transaction and I had to oppen the screen.inc file in order to change it, what if I had hundreds of screen.inc files? Should I go one by one changing the label?

In my option I should go to the column dictionary and update the label for each language, but only one update per language.

With my suggestion internationalization is straigh out of the box.
Re: Internationalisation suggestion [message #1397 is a reply to message #1391] Tue, 01 July 2008 05:37 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
Quote:

I belive my suggestion is easier to use, more flexible and it separates more the presentation layer from the data layer.

I do not see that it is easier to use as it holds column labels in the database completely separate from other text.

I do not see how it is "more flexible", just "different".

As for "separating the presentation layer from the data layer" I see that you do not have a clear understanding of what this means. It is far more complicated than dealing with label text.

Let me reiterate my point of view. My current design holds foreign language translations for ALL text in a single place, one file per subsystem per language. All text, whatever it is, is extracted using the same API. How could that be "improved" by holding some of the text in the database?

My current method works very well, so I see no reason to change it.


Re: Internationalisation suggestion [message #1399 is a reply to message #1379] Tue, 01 July 2008 05:41 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
Just answer this question:

I found myself wanting to change a label in a list1 transaction and I had to oppen the screen.inc file in order to change it, what if I had hundreds of screen.inc files? Should I go one by one changing the label?
Re: Internationalisation suggestion [message #1400 is a reply to message #1397] Tue, 01 July 2008 05:49 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
AJM wrote on Tue, 01 July 2008 05:37

Quote:

I belive my suggestion is easier to use, more flexible and it separates more the presentation layer from the data layer.

I do not see that it is easier to use as it holds column labels in the database completely separate from other text.


So why don't store all the other text in the database too?
Re: Internationalisation suggestion [message #1401 is a reply to message #1399] Tue, 01 July 2008 05:50 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
Although each *.screen.inc file contains a label for each column it is still possible to have an entry in the language_text.inc file which changes 'label-A' to 'label-B'. Thus you can make one change in your language_text.inc file which overrides every entry in multiple *.screen.inc files.

Re: Internationalisation suggestion [message #1402 is a reply to message #1400] Tue, 01 July 2008 05:54 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
Quote:

So why don't store all the other text in the database too?

Beacuse this would require a separate I/O for each piece of text. With my implementation a single I/O loads ALL the text for a entire subsystem into memory. Each call to getLanguageText() then references memory without any additional I/O.


Re: Internationalisation suggestion [message #1403 is a reply to message #1402] Tue, 01 July 2008 05:56 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
AJM wrote on Tue, 01 July 2008 05:54

Quote:

So why don't store all the other text in the database too?

Beacuse this would require a separate I/O for each piece of text. With my implementation a single I/O loads ALL the text for a entire subsystem into memory. Each call to getLanguageText() then references memory without any additional I/O.

The software I used to work with used a cache system to solve this.
I won't continue arguing Smile (but I still belive my suggestion is better Wink)
Re: Internationalisation suggestion [message #1404 is a reply to message #1403] Tue, 01 July 2008 06:05 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
Quote:

I still belive my suggestion is better

It is different, but not better. In fact it is worse because of the following:

  • text is split between database and non-database files - all my text is in a single file, one file per language.
  • it would require a separate I/O operation to retrieve each piece of text - my method has a single I/O operation to retrieve ALL text.
  • getting somebody to translate the text into a different language would require creating a new database record for each piece of text - my method has all the text for a single language in a single file.


Re: Internationalisation suggestion [message #1405 is a reply to message #1404] Tue, 01 July 2008 06:49 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
AJM wrote on Tue, 01 July 2008 06:05

Quote:

I still belive my suggestion is better


  • text is split between database and non-database files - all my text is in a single file, one file per language.
    Wrong. You could have everything in the database. Radicore programmers wouldn't have to deal with files. All metadata would be stored in the database.
  • it would require a separate I/O operation to retrieve each piece of text - my method has a single I/O operation to retrieve ALL text.
    Solved with a cache system.
  • getting somebody to translate the text into a different language would require creating a new database record for each piece of text - my method has all the text for a single language in a single file.
    Exactly. But an export and import procedure wouldn't be difficult to implement. Updates of any label would require just an update in the database



Your method: User has to deal with files. Updates introduce a ftp download, file editing and upload just to change a simple label or text. My method doesn't.



Re: Internationalisation suggestion [message #1406 is a reply to message #1405] Tue, 01 July 2008 07:32 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
Your method just affects the changing of column labels but has nothing to do with screen titles, menu buttons, navigation buttons and error messages. My method covers everything.

Besides, changing column labels is not something you do everyday. They are normally set once and remain for eternity.


Re: Internationalisation suggestion [message #1407 is a reply to message #1406] Tue, 01 July 2008 07:45 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
AJM wrote on Tue, 01 July 2008 07:32

Your method just affects the changing of column labels but has nothing to do with screen titles, menu buttons, navigation buttons and error messages. My method covers everything.

Besides, changing column labels is not something you do everyday. They are normally set once and remain for eternity.


No, you could use the same idea for everything. In fact, the software I used had every single string of text of the application in the database, so nothing was hard coded anywhere.
If you wnated to change any string you got into the dictionary and changed it.
You could have a table for error messages, a table for titles, for menu buttons etc. or everything in a single table.
Re: Internationalisation suggestion [message #1408 is a reply to message #1407] Tue, 01 July 2008 07:58 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
I could change my method, but I'm not going to. The cost of changing would not be outweighed by any benefits, so your suggestion is a non-starter.

Re: Internationalisation suggestion [message #1409 is a reply to message #1379] Tue, 01 July 2008 08:01 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
Time will tell..
Re: Internationalisation suggestion [message #1410 is a reply to message #1409] Tue, 01 July 2008 08:44 Go to previous messageGo to next message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
Time will tell nothing. The only way to tell if your suggestion has any advantages would be to implement it and make comparisons with the current method which I am not going to do for the reasons I have already stated.

Re: Internationalisation suggestion [message #1411 is a reply to message #1410] Tue, 01 July 2008 08:47 Go to previous messageGo to next message
bonzo_bcn is currently offline  bonzo_bcn
Messages: 152
Registered: June 2008
Senior Member
AJM wrote on Tue, 01 July 2008 08:44

Time will tell nothing. The only way to tell if your suggestion has any advantages would be to implement it and make comparisons with the current method which I am not going to do for the reasons I have already stated.

Sorry for trying to help.
Re: Internationalisation suggestion [message #1413 is a reply to message #1411] Tue, 01 July 2008 09:49 Go to previous message
AJM is currently offline  AJM
Messages: 2347
Registered: April 2006
Location: Surrey, UK
Senior Member
Although I welcome suggestions I am only interested in methods which are better, not just different.

Previous Topic: Future options
Next Topic: Transaction layouts
Goto Forum:
  


Current Time: Thu Mar 28 12:19:57 EDT 2024

Total time taken to generate the page: 0.02771 seconds