| Internationalisation suggestion [message #1379] |
Mon, 30 June 2008 15:46  |
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  |
AJM
Messages: 2371
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.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
| Re: Internationalisation suggestion [message #1385 is a reply to message #1383] |
Mon, 30 June 2008 16:37 |
AJM
Messages: 2371
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.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Internationalisation suggestion [message #1390 is a reply to message #1385] |
Tue, 01 July 2008 04:55 |
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 #1394 is a reply to message #1390] |
Tue, 01 July 2008 05:29 |
AJM
Messages: 2371
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.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
| Re: Internationalisation suggestion [message #1396 is a reply to message #1394] |
Tue, 01 July 2008 05:36 |
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 |
AJM
Messages: 2371
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.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Internationalisation suggestion [message #1404 is a reply to message #1403] |
Tue, 01 July 2008 06:05 |
AJM
Messages: 2371
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.
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
|
|
|
|
|
|
|
|
| Re: Internationalisation suggestion [message #1407 is a reply to message #1406] |
Tue, 01 July 2008 07:45 |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Radicore Forum
Search
Help
Members
Register
Login
Home
)
