
hey all, got this ide when I woke up this morning:how about moving the translation ( locale ) into the database? how would that work?we could have one translation table with data like: KEYFIELD:LANGUAGE_ONE:LANGUAGE_TWO TRANSLATION_ONE_key:LANGUAGE_ONE_TRANSLATION:LANGUAGE_TWO_TRANSLATION ... etc. any comments? /Greger

On Tue, Jan 06, 2004 at 02:41:40PM +0200, Bob Smith wrote:
hey all, got this ide when I woke up this morning:how about moving the translation ( locale ) into the database? how would that work?we could have one translation table with data like: KEYFIELD:LANGUAGE_ONE:LANGUAGE_TWO TRANSLATION_ONE_key:LANGUAGE_ONE_TRANSLATION:LANGUAGE_TWO_TRANSLATION ... etc.
please not! And then blow up the database for 24 languages? You must be kidding. What's wrong with the current approach?
any comments? /Greger
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
-- Regards, Wiktor Wodecki

Wiktor Wodecki wrote:
On Tue, Jan 06, 2004 at 02:41:40PM +0200, Bob Smith wrote:
hey all, got this ide when I woke up this morning:how about moving the translation ( locale ) into the database? how would that work?we could have one translation table with data like: KEYFIELD:LANGUAGE_ONE:LANGUAGE_TWO TRANSLATION_ONE_key:LANGUAGE_ONE_TRANSLATION:LANGUAGE_TWO_TRANSLATION ... etc.
please not! And then blow up the database for 24 languages? You must be
what blow up?jsut an idea, and it is all strings no problem ot handle in teh database. nothing wrong with the current approach either. My idea is to have the following, just as an example |-----STRING_KEY:--------|language one-----|-----language two-----| |MSG_WELCOME---|---VÄLKOMMEN-------|---WELCOME--------| |MSG_SAVE_TICKET|----SPARA TICKET------|---SAVE TICKET-----| ...etc I can't see anything wrong with thsi approach bear in mind that the number of strings representing the languages is *finite*, not infinite Best Regards Greger PS Can you explain how that would *blow up* the database? DS
kidding. What's wrong with the current approach?
I'm not going to do anything, I am not working on this project.
any comments? /Greger
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
-- Regards,
Wiktor Wodecki
------------------------------------------------------------------------ Name: signature.asc signature.asc Type: application/pgp-signature Description: Digital signature
------------------------------------------------------------------------ _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

Wiktor Wodecki wrote:
On Tue, Jan 06, 2004 at 02:41:40PM +0200, Bob Smith wrote:
hey all, got this ide when I woke up this morning:how about moving the translation ( locale ) into the database? how would that work?we could have one translation table with data like: KEYFIELD:LANGUAGE_ONE:LANGUAGE_TWO TRANSLATION_ONE_key:LANGUAGE_ONE_TRANSLATION:LANGUAGE_TWO_TRANSLATION ... etc.
please not! And then blow up the database for 24 languages? You must be kidding. What's wrong with the current approach?
What is wrong with the current approach is perhaps that it is error prone to translate, and you have to know perl to do it. I translated the german to swedish. with a new approahc we could hire a translator for 4 hours and he/she could do the translation through a web interface to the otrs. or volunteer to do it. we could thus use translators for translating, and coders for coding. we could easily extend the langagues otrs translated to to a large number of languages. alright so I expect some comments on this approach, I'm not going to change anything in the otrs until ((otrs.de)) hires me. /Greger
any comments? /Greger
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
-- Regards,
Wiktor Wodecki
------------------------------------------------------------------------ Name: signature.asc signature.asc Type: application/pgp-signature Description: Digital signature
------------------------------------------------------------------------ _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

Greger,
alright so I expect some comments on this approach, I'm not going to change anything in the otrs until ((otrs.de)) hires me.
Either sarcastically put or with all seriousness intended, this really boils down to a rather poor demonstration of appreciation for the work that the developers and contributors of this software have done to get OTRS to the state it is today. If you have constructive comments to share regarding potential modifications to the OTRS system, please share them. But for my own sake and the sake of those interested in furthering the development of this open source system, I kindly ask that you refrain from posting comments that are likely to incite others and may be considered offensive and ungrateful from those that have made contributions to the source. With regards to the language system, the simplest way of providing translations of the software would be to create language files containing the appropriate phrases for each language. This would make installation of languages and future translations simple and is pretty standard practice for other installations. There's no reason to put unnecessary overhead on the SQL backend to display translations, and as the number of languages increases, so will the base size of an OTRS install. Best wishes, Paul

lists@neenerville.com wrote: It has never been my intention to cause harm to anyone I like the idea of otrs, it is a great product, but it is far from finished. I appreciate the effort and time, and most of all *knowledge*, put into the project. All critisism is in fact constructive, if one can't stand critisism of one's own work, why be in the business in the first place? There is no silver bullet, there is always alternative ways of doing things. And as this is a forum for discussing otrs, I posted here.
Greger,
alright so I expect some comments on this approach, I'm not going to change anything in the otrs until ((otrs.de)) hires me.
Either sarcastically put or with all seriousness intended, this really boils down to a rather poor demonstration of appreciation for the work that the developers and contributors of this software have done to get OTRS to the state it is today.
If you have constructive comments to share regarding potential modifications to the OTRS system, please share them. But for my own sake and the sake of
wasn't what I mailed sharing opinion of possible improvement?
those interested in furthering the development of this open source system, I kindly ask that you refrain from posting comments that are likely to incite others and may be considered offensive and ungrateful from those that have made contributions to the source.
As I wrote above I have never thougth of hurting anyone, but each one participating should be prepared to get critisism. If nobody says nothing, then how can things improve?
With regards to the language system, the simplest way of providing translations of the software would be to create language files containing the appropriate phrases for each language. This would make installation of languages and future translations simple and is pretty standard practice for other installations. There's no reason to put unnecessary overhead on the SQL backend to display translations, and as the number of languages increases, so will the base size of an OTRS install.
Thank you! That was the discussion I was waiting for. But you are still missing the point in my earlier mail regarding locale and translation. On the other hand it all boils down to where otrs should go in the future. When I was studying we had a doctor in business management and administration which pose a very good question to me once. He asked:"What business problem are you trying to solve?" I think ( no offence!!!!) that otrs should undergo a constructive debate as to where otrs want to go in the future. The debate is necessary to be able to determine the future road for otrs. Otrs is great, but can be made *even better*! Best Regards and no offence to anyone /Greger
Best wishes, Paul
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

Hi, On Wed, Jan 07, 2004 at 03:09:26AM -0500, lists@neenerville.com wrote:
[...] With regards to the language system, the simplest way of providing translations of the software would be to create language files containing the appropriate phrases for each language. This would make installation of languages and future translations simple and is pretty standard practice for other installations. There's no reason to put unnecessary overhead on the SQL backend to display translations, and as the number of languages increases, so will the base size of an OTRS install.
I agree with Paul (it's faster for the application (because you don't need to do db queries) and it's easier to change/update/add just one or two translations). However, thanks for the idea! :-)
Best wishes, Paul
Martin Edenhofer -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Manage your communication!
participants (4)
-
Bob Smith
-
lists@neenerville.com
-
Martin Edenhofer
-
Wiktor Wodecki