EKON Spring - Thursday Session#

At the EKON Spring, I'll present a new solution for multi-language VCL applications. It allows you to translate all forms and resource strings in an external application, comes with a command line tool for updating strings. Every language resource can be deployed seperatly, the application can be deployed without any additional resources at all - in the original developer language.

In a second step, I'll probably will not show that at the EKON Spring yet, you can save translations of forms and resource units for later projects to use.

Stay tuned for more, I'll present that here after the EKON for download ;-)

Best of all, there will be a fully usable version for free.

Sunday, February 17, 2008 10:10:33 PM (W. Europe Standard Time, UTC+01:00) #    Comments [5]  | 

 

Google AdSense


Monday, February 18, 2008 9:50:14 AM (W. Europe Standard Time, UTC+01:00)
Moritz Beutel
Monday, February 18, 2008 10:00:40 AM (W. Europe Standard Time, UTC+01:00)
sounds really awesome!
grenzi_r
Monday, February 18, 2008 10:16:55 AM (W. Europe Standard Time, UTC+01:00)
GNU gettext ist a solution, however, I do not like the translation software of it very much. It is just not flexible enough for me. Mine is in development and I have full control over it and how I want to use it. This makes it very easy for me to adjust for new features.

If you have any suggestions, please, let me know ;)
Monday, February 18, 2008 5:31:30 PM (W. Europe Standard Time, UTC+01:00)
My suggestion would be to use dxgettext as backend and adapt your translation software to the gettext file format (I do not like poEdit very much either). There are many things that can be done better, e.g. visual translations with something like a form designer.

However, if you want to create your own localization system, your solution should at least provide all features which are provided by dxgettext (embedded translations, change language at runtime, support for C++Builder etc. pp.).

Do you want to reveal some of the benefits of your system over dxgettext?
Monday, February 18, 2008 5:52:27 PM (W. Europe Standard Time, UTC+01:00)
Well, in short, I wont either. I will not provide another front end for dxgettext, and I wont provide all features. And I don't think I have to ;-) Why, because it is growing with my needs, and those who request a special feature. The idea is to provide an easy to use solution and dxgettext is not, imo. With an easier use, some features are dropped. For now, there is no C++Builder support, but to support C++Builder, all files needed for translation are in the bundle as source code.

The idea of my solution is, that during development you don't have to think to much about translating everything. You can even create a multi-language project as an afterthought without much work.

You can change language during run-time, yes. This is one of the requirements I had for myself. I am not sure what you mean with embedded translations though.
Comments are closed.
All content © 2008, Daniel Wischnewski
On this page
Archives
Promoted Links
Blogroll OPML
My current Flickr Images
www.flickr.com
Dies ist ein Flickr Modul mit �ffentlichen Fotos und Videos von dwischnewski. Ihr eigenes Modul k�nnen Sie hier erstellen.
Recommendations
Sitemap
Special Pages
Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Theme design by Jelle Druyts