Translating text keys at run time - translation system

[TheBerliner]

Hello,

Websites and web applications must be multi-lingual today. Absolutely mandatory!

It has always been our practice to equip our code with text keys, which are translated into the user-selected UI language at runtime from a translation dictionary.The same should be available to JavaScript code but I found no such tools. Is anybody aware of such tools? And I think that this would be a vital enhancement of EXT JS.

My ideas about what should happen:

All JS code contains nothing but text keys so that only one library is sent out no matter which language the user has chosen. The translations are sent an an extra JSON file and used by some central module to translate the text keys.

A simple syntax example for setting a title in the selected language. This could look like this:
title: translate('myTextKeyForThisTitle')
where the function translate answers the string in the currently selected language.

Actually, in our desk-top software, the actual translation is done at the very last point deep inside the UI library. The same should be contained in EXT JS so that an even simpler syntax could be used:
title: 'myTextKeyForThisTitle'
where there is the problem that (ASFAIK) JavaScript does not know symbols (as does Smalltalk) as a special form of Strings. So there must be some way to detect that what is sent as aString really is aSymbol. JS experts perhaps know some hack to circumvent this lack of symbols in JS. A simple way would be to assume aSymbol if the first character of the string is a #. This is btw how Smalltalk (grandmother of all OO languages) defines symbols.

So the text key above would spell like this: #myTextKeyForThisTitle. The translation module can then process keys and strings although it is never any good practice to have language strings in code anyway.

How have you/others solved this?

Another improvement: The symbol (text key) should also be used to reference the user documentation.

Best regards from multi-lingual Europe

[pmatsumura]

Hi,

this is actually the wrong thread for your post, since this thread should be used as a pool of
Ext language files of users. But I'll try to answer some of your questions. Also I would like to ask a moderator or an admin to move this post and the one from TheBerliner to a seperate thread. Thanks in advance for that.

First of all the Ext language files do not only contain translations of strings. They also provide date or number formats. Then if you create a web application you pretty sure use some kind of scripting language that generates HTML. You could then include the correct Ext language file and your dictionary file according to the language selected. Defining a title like so


title: translate('myTitle')should work fine as long as you defined that translate function correctly. But if you let a script generate the javascript code, then you could set the title while creating the output.


where there is the problem that (ASFAIK) JavaScript does not know symbols (as does Smalltalk) as a special form of Strings. So there must be some way to detect that what is sent as aString really is aSymbol. JS experts perhaps know some hack to circumvent this lack of symbols in JS.Why would you want to do that? Just curious, because I would just define a variable, or if I used your translation function, I'd define a dictionary array with keys, each holding a translated value.

Thanks,
Patrick

[Animal]

Hi from multi lingual Europe (perhaps 50% of the Ext user base is in Europe. Most of my private clients are)

Is this about how to internationalize your own web app?

You could do it how Ext does it with language-specific property files from which all prompts and messages are drawn. Ext is fully internationalized and will offer all library-specifc prompts in local languages.

http://i131.photobucket.com/albums/p286/TimeTrialAnimal/lang_de.jpg

[TheBerliner]

Hello Patrick,

thank you for your confirmation that my proposal would work. I had no doubt about that. And I am also aware that there are no concrete language texts in the EXT JS lib, which is a very good point (few Anglo-Saxon originating tools have this).

So fine, so good.

Still, taking into account that presumably a large portion or even most of the EXT JS user write multi-lingual apps, I thought that this would be a useful enhancement for one of the next releases.


Why would you want to do that? Just curious, because I would just define a variable, or if I used your translation function, I'd define a dictionary array with keys, each holding a translated value.

There are very very many good reasons. Any Smalltalker would agree to that. But to understand them, you would have to know the unmatched Smalltalk development environment and "philosophy". Please remeber that all of today's OO languages (except Lisp) were modeled after what Smalltalk has had for >25 years.

One single example: In Smalltalk I can get immediately all usages (senders and implementers) of aSymbol - but, or course, not of a string. Also, we often use Symbols to generate code and we even more often send symbols as messages. Look for "Smalltalk perform" and you will find more. The "perform" is one of the most powerful features, as it uses data as code. BTW: We rarely work with variables (for app/user data), in 99% of all cases this is in dictionaries, as this approach is 100% dynamic.

Best regards

[TheBerliner]

Hi from multi lingual Europe (perhaps 50% of the Ext user base is in Europe. Most of my private clients are)

Is this about how to internationalize your own web app?

You could do it how Ext does it with language-specific property files from which all prompts and messages are drawn. Ext is fully internationalized and will offer all library-specifc prompts in local languages.

Very good to hear. I am still in the process of getting to know EXT JS (writing an interface class tree).

But I was thinking of the application texts, not (so much) of the EXT lib, which I considered to be multi-lingual.

Again: Translation can be done as proposed and confirmed above. But I think that it makes little sense for the many users to re-invent the wheel. Therefore my proposal.

My concrete problem: I soon have to decide, which of the two ways to proceed. I would very much prefer to add pseudo-symbols only (= strings starting with a "#") and to have this translated at one (or a few) central points. This is much better than having thousands of function calls locally to translate(). Problem is: Where to add that in the lib.

So I propose one Translation class, which is called from your class library and which offers this translation service at one central place. It would also cache the JSON files in the user-selected language. BTW: I still have not yet found a real good Dictionary class in JS that does at least the most basic jobs (of what we in Smalltalk are expecting from aDict). Greatful for any hint!

Regards

[Animal]

Not sure what you mean by Dictionary class.

Could you describe what you want?

[evant]

As previous posters have suggested, you're best off checking out how Ext does the language files. This is generally considered the simplest and most effective way of providing internationalization. You could model your own after these (or some similar construct).

[TheBerliner]

Not sure what you mean by Dictionary class.

First of all, let me remind you that Smalltalk is the original pattern after which all of today's OO languages (except Lisp) were developed, although most only to a very small degree.

Smalltalk comes with a brilliant ingeniously developed (at the famous PARC in the 70-ies !!!) "foundation class library", which comprises of several Array, Collection and so forth classes. (Not only) in this respect Smalltalk is much more powerful (and mature) than JavaScript and also than Java (my son develops/fights with Java).

Dictionary is one (of the most important) of them. Several Collection types are others. I am enclosing a few links to sources that explain well:

http://www.delorie.com/gnu/docs/smalltalk/gst_52.html
Very good is this:
http://stephane.ducasse.free.fr/FreeBooks/HopkinsHoran/HopkinsHoran.pdf page 140
Less detailed:
http://www.cincomsmalltalk.com/documentation/current/BasicLibraries.pdf PDF page 22

Essentially, a Dictionary is a holder of key/value pairs, both of which can be "real" (complex) objects.

Hope that helped. May I recommend you (by no means as critics) to read a little bit more into these concepts, because it's always good for a modern musician to know what the forefathers like Bach and Mozart have done - to use this analogy.

Best regards

[Animal]

Oh. An advert for Smalltalk?

Anyway.

What you describe is called in Javascript "an object"



var myObject = {
key: 'value'
};


Simple as that.

And if the key must contain characters which cannot be parsed then



var myObject = {};
myObject['#foo-bar.bletch'] = 'value';

[TheBerliner]

Oh. An advert for Smalltalk?
Referring to the original when discussion partial copies of it!

You answer shows that you neither know what a Dictionary is nor that you have looked at the links where this is explained. And in this case, a Dictionary is a (relatively well) standardized term of this industry - since the late 70-ies, btw.

Best regards

[Animal]

Please explain more if this construct does not provide the functionality you require.

[pmatsumura]

Just tell us what exactly you are trying to achieve here. Why don't you just let Smalltalk generate your Javascript code. Then you can use all your Smalltalk stuff to do rest, like dictionaries.

Patrick

[Animal]

The OP thinks that I do not understand the concept of a dictionary (by PM).

The reason I asked for clarification is in case the OP had a different concept of what a dictionary was.

Because he was confused over config objects. And that is a classic case of using an Object in its form as a dictionary: Passing named values, each of which may refer to any object type.

I'm not sure what further requirements the OP has since he has stopped responding.

[TheBerliner]

Please explain more if this construct does not provide the functionality you require.
It seems that there is no special implementation of a Dictionary available in JavaScript (I failed to find any over >1 hr searching). A (proper) Dictionary needs a lot more than just making some string compare. It is a fairly complex implementation with hashing etc to achieve results very quickly. Also, the protocols are quite well defined ("de-facto-standards").

So, nothing "is as simple as that".

Therefore, without a proper and fast Dictionary implementation the translation will work only very slowly and badly. In my eyes, such basic classes (also Collections ect) are mandatory building blocks and I wonder how one can work without them.

As I wrote in a PM to you, if you don't know what aDictionary is you should first read into the links that I have posted above.

[TheBerliner]

Just tell us what exactly you are trying to achieve here. Why don't you just let Smalltalk generate your Javascript code. Then you can use all your Smalltalk stuff to do rest, like dictionaries.Patrick
Patrick,

That is what we are about to implement for 3.0 (had been done before for 1.1). But that does not solve the translation problem in the client or we would have to generate the JS for every request, which would mean a hell of wasted CPU time and traffic. This is why the (our) JS library should be free of language dependent text and just refer to a translation object. But I have no clue how this could work well without having a Dictionary as essential building block.

Clear?

regards

[evant]

I think everyone is quite clear on what a dictionary is. However what you've asked for is a simple way to do internationalization in Javascript. We've pointed you to a number of ways of doing it. To be honest, I don't see why you'd need "complicated" dictionary methods, a simple string lookup will definitely suffice for a basic string replacement.

[evant]

var Translation = {
Yes: 'Да',
No: 'Нет',
Hello: 'Здравствулте'
};

var name = 'foo';
console.log(String.format('{0} {1}', Translation.Hello, name));


Dump (or include) the appropriate translation object at runtime. That's all you need to do, the basic javascript object can act like a dictionary. Unless you've got hundreds of thousands of items being translated, the lookup time is trivial.

[TheBerliner]

The OP thinks that I do not understand the concept of a dictionary (by PM).

The reason I asked for clarification is in case the OP had a different concept of what a dictionary was.

Because he was confused over config objects. And that is a classic case of using an Object in its form as a dictionary: Passing named values, each of which may refer to any object type.

I'm not sure what further requirements the OP has since he has stopped responding.
1) What a Dictionary is and what it does has been defined >30 years ago at PARC. Everbody else who came later should not try to redefine this.

2) Therefore, this world does NOT need MY definition of a dictionary (or anybody else's).

3) What do config objects have to do with a Dictionary? I found nowhere a precise defintion of what "config objects" are. So let's keep this apart. And in case that config objects are some kind of holders of definitions, they are not automatically dictionaries because of that.

4) "using an Object in its form as a dictionary"
Proves that you have not understood what a Dictionary is. "A" object is never a Dictionary but, of course, a Dictionary is alwyas "some kind of " object. Pardon, but it is just ridiculous to claim that in JS just any type/class of Object could serve as a dictionary - provided one knows how a dict works. And I am not coming to the polymorph protocols that it should share with Arrays and Collections. That'd be "advanced requirements".

5) "Passing named values, each of which may refer to any object type."
A Dict does not serve for "referring to any object type". Instead, it acts as the holder of instances (ideally of any class) and it answers the value when being asked for a key both of which should (ideally) be either basic (in JS data types) or complex objects. But, of course, Dicts can also be traversed sequentially (rare exception) and a lot more things should be available like creating them from Collections and vise-versa.

See the explanation of a dict in the links above.

[TheBerliner]

var Translation = {
Yes: 'Да',
No: 'Нет',
Hello: 'Здравствулте'
};

var name = 'foo';
console.log(String.format('{0} {1}', Translation.Hello, name));
Dump (or include) the appropriate translation object at runtime. That's all you need to do, the basic javascript object can act like a dictionary. Unless you've got hundreds of thousands of items being translated, the lookup time is trivial.
Of course, there are thousands or tens of thousands of entries. Our current translation table has about 8.000 entries alone (per language).

A sequential string compare is nothing that I would ever consider. Just FYI: in our world accessing dicts is almost (= hardly any difference measurable) as fast as accessing instance variables. This is why we hardly ever work with instVars (never for user/app data and also because they are far "more" static). Even our model definitions including DB table and field definitions is all in data, which is held in dicts. Just as a background.

I am not expecting "our world" in JS, of course, but sequential string compare is out of any question, especially since I feel (= not sure, not measured but strong impression) that the JS interpreters in the browsers are extremely slow. This must be solved with some good hashing algorithm. I have programmed this (hashing based database) in the last 70-ies - but I am not going to do this again today.

[evant]

Only 8000?



Ext.onReady(function(){
var o = {},
i
result,
start,
finish;

for (i = 1; i <= 100000; ++i){
o['foo' + i] = 'foo' + i;
}

start = new Date();
for (i = 0; i < 10000; ++i){
result = o['foo' + Math.ceil(100000*Math.random())];
}
finish = new Date();
console.log(finish.getElapsed(start));
});


That takes about 15ms to run on my machine, doing a simple string lookup 10000 times on a "dictionary" with 100000 items. If 15ms is unacceptable for that kind of thing, then you've probably chosen the wrong language ;)

Anyway, we seem to be going round in circles here, so I'll leave you with that. Good luck!

[TheBerliner]

If that's the case, this part of the discussion was a waste of time. But allow me to doubt that.

[TheBerliner]

I did not want to extend this discussion. It was originally based on my proposal and question how to solve the translation problem.

As a resumee, I have to state that there seems to be no specialized Dictionary object available for handling translation (and other similar tasks). I will look out again, perhaps is there any tool but I almost doubt it.

Therefore, I will have to think about some hack to circumvent this (in my eyes) great problem and lack of basic tools. Of course, we all know that JS (and HTML) is/are used today for complexities that they were not planned for in the beginning. But I do hope that the tool and interpreter writers finally catch up to what people (also like me) are usin these environments for today.

Thank you in any case for your contributions and if you have any better proposal than string compare (which I would never have called a dict), I would appreciate if you let me know.

Still my personal recommendation is to read a bit more into the "acient" original world of "everything is an object" that was developed at PARC. I have had similar discussions with "joungsters" who thought that their tools, just because they are "rencent" and in the hype, were superior and state of the art. Unfortunately, the God (or Luzifer) if profits often prefers newer and less intelligent designs over mature and superior ones. C++ for example is a lousy piece of [here was a four letter word starting with sh and ending with it - this silly "politically correct" forum software seems to filter the truth, PC is enforcing us to lie, therefore figth this PC desease!] and was developed when Smalltalk and Lips were already teenagers. And there are more examples.

BTW: My strong impression is that the guy(s) who designed the EXT JS library and the protocols must have at least good theoretical knowledge of the world that I am takting about, because I found lots of very familiar terminology. That is good, of course.

Best regards

[pmatsumura]

I think that you are in your world and don't seem to like our world. I think you made your point in telling us, that we use stupid languages and are (probably) to stupid to understand you and your problem. We know what a dictionary is and I think it's pointless to tell you, that Javascript is not and will never be Smalltalk.

Patrick

[TheBerliner]

No Patrick, you are wrong: I don't consider anybody else stupid unless I know this person (with the exception of politicians who prove what they are every day) or until he has convinced me several times.

But there are simple environments and more complex ones and it is not my judgment into which category Smalltalk falls. And if somebody is trying to sell "any object" as dictionary and the same person (in another thread) does not see the difference between a whole class tree and one single branch and does not acknowledge that there are very different things labeled to be a "class", then I just have to explain some real basics.

Best regards

[jburnhams]

TheBerliner - you are now my favourite poster! Please continue sharing your wisdom.

[dj]

Hi TheBerliner,

I can free you of the need to create a dictionary implementation for your translation needs.

Accessing a property of an object is a fundamental thing in JavaScript. To my knowledge, it is not specified in the standard (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf) how that should be done. But every JavaScript engine I tested (http://ext.wirsind.info/access-object-properties.html) (IE, Firefox, Opera, Safari, Chrome) has optimized that quite well.
Your fear that it is done with sequential string compare is ungrounded. What gave you the impression in the first place? In fact, the access time does not change with the size of the object. Accessing a property 100,000 times on an object with 1,000 properties takes the same time as accessing a property 100,000 times on an object with 1,000,000 properties; depending on the JavaScript engine from 10ms to 100ms on my machine. (That is 100,000 accesses!)

I seriously doubt that any JavaScript implementation of a dictionary can be as quick as this. Even the most ingenious solution is a JavaScript-one and can hardly compete with the highly optimized C/C++ implementation of the JavaScript engine.


Go ahead, test for yourself: http://ext.wirsind.info/access-object-properties.html

[TheBerliner]

I seriously doubt that any JavaScript implementation of a dictionary can be as quick as this. Even the most ingenious solution is a JavaScript-one and can hardly compete with the highly optimized C/C++ implementation of the JavaScript engine.

Go ahead, test for yourself: http://ext.wirsind.info/access-object-properties.html
Hello Dj,

good news and thank you for the comments.

Of course, the low-level implementation of Dicts is in the virtual machine and therefore in C/C++. This is why there are special classes, which apart from standardized polymorph protocols - in the end - divert into the VM, which does the speedy job and which uses hashing. Insofar, my "JS implementation" was not precisely what I really meant and that was not "all in JS", of course.

It's a pity that these people who consider what they call "modern" environments as the only state-of-the-art are mostly unwilling to learn from what has earlier been done in a much better way (see Java as a good example, which still lacks many goodies). "Modern" often is not better.

One of the strengths of Dicts is in their polymorph protocols with Collections, Sets and other classes, none of which is available (ASFAIK) in JS, except Arrays in a very simple form.

But, of course, this is not concerning EXT but related to JS only.

I will see what the performance is when it comes to real life. Still, a central translation class/function would enhance EXT JS.

Mit herzlichen Grüßen

[tomim]

Hi TheBerliner,

As I understand, you would like to have general implementation for support for multiple languages but
with less programming as possible (or without any programming at all).
Like automatic translation or automatic switching to different languages without additional programming effort.

I have searched for something like that,but no luck for now so I decide to write my own.

Now, I am working on a such add-on for automatic translation of all the components inherited from Ext.Component.
This add-on contains 2 base singleton objects Ext.translate.Manager and Ext.translate.Cache and
Ext.Component override to add features of automatic translation.

It is not exactly a dictionary you wrote about, but translations are stored in a cached object (client and server side). It use standard key/value pairs.
New components when created interactively (by user interaction) search in mentioned cached object for already
translated data for specific fields/properties to minimize calls to the remote server.
All translations are "indexed" in a manner of field/cached_object relation.

There is a link to the project... http://code.google.com/p/extjsdyntran/
and main post http://extjs.com/forum/showthread.php?t=72978

Regards,
Tom

[TheBerliner]

Hello Tom,

The thank you very much for taking up my proposal and coming back to the subject and even more so thank you for writing some add-on. I would like to have done that but my knowledge of JavaScript in general and of EXT JS in particular is still by far too small to let me dare starting such a project.

But since I'm having quite long and substantial experiences with this subject, perhaps would you be interested in hearing some more ideas and in reading how we have solved this in previous environments, namely in Smalltalk applications.

Typically, a user selects his preferred user interface language from a menu when starting the application. This is stored in some ini file. In the case of a browser, I would take the language identification that is sent as part of the initial request as a first hint. If somebody is running, for example, an English browser but wants German (or any other language) as the content language (my case), he then has to select his language manually.

In any case, some language is selected and only the dictionary for this one language should be loaded by the browser as there is no need to have more than one language at a time.

My idea was that this data should be loaded from the server presumably in some JSON format so that the initial HTML header, which is sent out by the browser, contains a link to this translation file. Ideally, sending this translation file should only affect the Apache file server (and not any PHP server or similar).

From my point of view, this is the simple side. Where I did not know how it could be handled is in all the properties of EXTt objects, which are language related.

I see two alternatives, where the first is the preferred one:

1) Use the symbols as language keys

My idea was that instead of adding a string with some explicit (and then always language dependent) text, one would equip this with what in other environments (namely in Smalltalk) is called a symbol. A symbol is a special kind of string, which is handled somewhat differently in that it can be used as a method accessor or an identifier for some code or data. Such symbols are typically stored in dictionaries as the key part of key/value pairs but I meanwhile found out that what in JavaScript is called an Array, actually behaves partially like a dictionary. When making my first post I was not yet aware of this (it's a pity that all language authors feel obliged to use their own distinct terminology in contrast to what had been done before).

I don't see a problem in the fact that JavaScript doesn't know symbols, because this can easily be substituted by just using a string, which starts with a distinct character. I would propose to use the hash sign (#) as the first character to identify symbols, not only because it is used in Smalltalk but also because it is almost never used as the first character of some string.

The second condition for such a symbol in order to be logically compatible to other languages should be a requirement that it doesn't contain blanks but that is of less importance.

Therefore, all that would have to be done in a few central places where such pseudo-symbols are stored, is to interpret such a symbol string as a text key and hence to look up the value in the translation object.

Instead of the pseudo symbol, the translated text is stored when a language dependent property of an EXT element is set with some text value.

I assume that this would affect only a few setter methods of those properties, which store user interface text. This should not be mixed, of course, with application data, which in this respect is independent of language (the language selection must happen on the server).

This would enable the developer to just write on single copy of JavaScript code, which includes the text key symbols instead of explicit language text. Having concrete user interface text in code is bad style anyway in my view. All translations would be done when the text key symbol is added to some new instance of the affected EXT JS classes.

Another great advantage of this practice (which BTW I have been using since the early 80-ies), is in the fact that such text keys are much easier to detect and to parse. The following has nothing to do with the translation object but it may be helpful hints to other readers: In our practice it has proven useful to distinguish between different types of text keys and to use very stringent syntax for them.

We distinguish between / starting with:

menu key: #m_menuBlahBlah (this includes buttons)
tab keys: #t_tabTitleBlahBlah
field keys: #f_fieldLabelBlahBlah
notes to users: #n_SomeTextBlahBlah this identifies user notifications
and a few more. Again, I am mentioning this only as a little hint and this has, of course, nothing to do with the translation subject as such.

Note that it is good practice to have all text keys unique. In some cases, there exist even more than one text key for one can text string, which is often needed when essentially the same information is to be presented in different places and/or inside different spaces.

2) Adding a call to a translation function to the senders of setter methods

If for some reason this first proposal would not work, I would see another possibility although I regard this as the less attractive. In this case, a function call to some central translation library would be added together with the above-mentioned text key in all places where language dependent texts are added to an EXT JS instance. This is not only more cumbersome but creates code redundancies, which I am always trying to avoid, also because the only code that this bug free is the one that was never written!

I am not quite sure what you mean with this:


It is not exactly a dictionary you wrote about, but translations are stored in a cached object (client and server side). It use standard key/value pairs.
New components when created interactively (by user interaction) search in mentioned cached object for already translated data for specific fields/properties to minimize calls to the remote server.

If I have to understand this in a way that the client would make a request to the server for every single text key, then this is simply unacceptable, because it would cause a tremendous amount of unnecessary server load. Additionally, this would not be needed when implementing my first proposal. By the way: in our desktop software, the software administrator (technically a user) can change all translations to his preferences.

I also cannot comment this either:

All translations are "indexed" in a manner of field/cached_object relation.
because I really don't understand what you mean. I see absolutely no need to build a relation between a field or text key (?) and some UI element object. All text keys must be unique and this is also why one can even identify any UI element via its text key. In fact, in our case the identification of any UI object is always identical with the text key except for the first two characters of the text key like in "#m_" (please note that there hash does not count as a character)
.
Therefore, a menu item with the text key #m_menuMainView would always be held by menu object with the ID #menuMainView.

Again, this is by no means a must but just a practical example from development experience and large projects. It is often a bit difficult to force developers to adhere to such stringent syntax and it needs a lot of discussions and fighting, but it always pays back, especially when the developer changes and somebody else must maintain or enhance other people's code.

Please see my comments as recommendations from my experience and I should be pleased to give you more if needed and welcome.

I most curious to hear about your development and I would like to assist you but I am still quite incapable of doing so in JavaScript. On the other hand, I am hoping to have my EXT JS class generator working in a two to three weeks (some first objects are already generated) and I could then use this as a first practical test environment. In my previous work I was already assuming a solution as my proposal one. This is what I am currently implementing in Smalltalk in order to ride out JavaScript code from it.

In case that this wouldn't work, the change could still be done when the JavaScript is generated by Smalltalk. As a worst-case scenario, I could create automatically one JavaScript library, each of which includes translated text, for every needed user interface language, but of course this is not the preferred solution.

I apologise for not having had the time to cut myself shorter, but I was again using voice recognition, which makes it fairly easy - but not bug-free - to write down thoughts.

Best regards

[TheBerliner]

Hello Tomislav,

I have only read your links after making my first reply and I want to comment what you're writing on the Google project page:

Dynamic translation by Google Translation Service API
Just forget about that! I have never yet come about any translation service, which would work. The translations supplied are ridiculous at best!

Perhaps, there is a substantial misunderstanding: My asking for a translation was not to automatically translate content, because that does not work and that will not work for the foreseeable future. All I was asking for is essentially a simple string replacement, where the text key (what I call a symbol is a text identifier) is exchanged by some concrete and well prepared translation.

Of course, such translations can only be done by knowledgeable people who know the subject of the application software and the application environment. There is absolutely no chance to even think of an automatic translation by some software!

So my impression and fear is that your thoughts and your project go into a completely different direction and, honestly, I don't see where this could be used in practice.

From your name I assume that he are from the Serbo-Croatian language area and this is a part of the world where dialects are very important. From my friends in Beograd I heard not too long ago that this one language "Serbo-Croatian" (leaving all politics aside) is currently starting to drift apart for political reasons, because people in the countries where this is spoken are inventing new words to distinguish from their neighbours (merely because of politics). How could such things ever be handled by a software!?

The good news from your introduction page is this phrase: "Translations can be retrieved from server side file".

I assume from this that my proposal with text keys (symbols) could also be implemented. At least I hope so.

Unfortunately I cannot run your example, because I have neither the time nor the experience to set up Java, Tomcat and all of this and my schedule is full up anyway.

Best regards

[jburnhams]

I believe that in Javascript, key/value pairs are called Objects. An Array is a specific object and is meant to be used for numeric keys. This page (http://andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/) explains the difference.

[TheBerliner]

I believe that in Javascript, key/value pairs are called Objects. An Array is a specific object and is meant to be used for numeric keys. This page (http://andrewdupont.net/2006/05/18/javascript-associative-arrays-considered-harmful/) explains the difference.

Well, calling something specific just "an object" is in my view neither very expressive nor helpful. "object" and "class" are probably the two most abused words in the IT industry, especially because everbody means something different. To call CSS "classes" as such is a bad joke and a good way to confuse o-o people like me in the beginning.

The author of this page proves in the first lines that he has very little o-o knowledge. It's absolutely normal that Arrays can store any data type etc etc

[jburnhams]

Perhaps you would find it useful to read a tutorial about Objects in javascript? This one (http://www.techotopia.com/index.php/JavaScript_Object_Basics) looks quite helpful.

[TheBerliner]

Perhaps you would find it useful to read a tutorial about Objects in javascript? This one (http://www.techotopia.com/index.php/JavaScript_Object_Basics) looks quite helpful.

Thank you for your proposals and the link. This one looks quite helpful at first glance.

I am currently and almost simultaneously learning JavaScript (from various manuals) and the EXT JS API while writing a JS code generator to create EXT JS objects from within my (Smalltalk) environment and filling it with concrete EXT objects in our notation (essentially all key/value pairs) and with great re-use.

Testing will be the hard part and that is still ahead of me.

The only problems I am having is in understanding the JS syntax (which I often find quite dubious, being spoiled by the extremely simple and obvious Smalltalk syntax). Also fighting the bracket chaos is in my view a waste of time. Another reason why I want to automate this JS code generation.

[jburnhams]

I think the ability of javascript to create Objects and Arrays using only brackets (object literal notation) makes it both concise and powerful. I find it hard to believe that smalltalk could be better in this regard - doesn't it suffer from the same verbosity as other older languages?

[TheBerliner]

I think the ability of javascript to create Objects and Arrays using only brackets (object literal notation) makes it both concise and powerful. I find it hard to believe that smalltalk could be better in this regard - doesn't it suffer from the same verbosity as other older languages?

I am not a Smalltalk missionary - just an advocate! :)

It is never essential how long it takes to write code! It is always multiple times more important to find code and to easily debug it!

Arrays in Smalltalk are different and (intentionally) less powerful than in JS. JS Arrays are a mixture of Smalltalk Arrays, Collections and Dictionaries, where the two latter ones in Smalltalk are far more powerful than JS Arrays.

In Smalltalk, an Array is created in one of two ways:
myArray:= #(#symbolOne 12 'SomeString' 1). (The starting # before the opening bracket is a shortcut for creating an Array). This is exactly the same as in JS. Any type of object can be inside the Array.

or, the longer syntax:
myArray:= Array with: #symbolOne with: 12 with: 'SomeString' with: 1.
This creates an identical Array instance from a multi-argument message.

Must better is this: myCollecton:= #(#symbolOne 12 'SomeString' 1) asOrderedCollection
(or several other sequentiable object types). The primitive Array is only used for intialization and it's then converted to something more useful.

One of the greatest differences between JavaScript and Smalltalk is in the fact that Smalltalk supports multi-argument messages, which is not supported by JavaScript. To circumvent this deficiency, JavaScript uses these very simple pseudo-objects (also in EXT called config objects) in brackets. I don't think that this is a concise syntax or a "good thing" and it is very difficult to find such pseudo method calls in a large project. The lack of Symbols is also very bad.

Probably the greatest advantage of Smalltalk is in its ability to immediately show all senders and all implementers of any class, method or symbol.

We never search in files and we have a debugger environment that all other languages don't even dream of! Any Smalltalk browser immediately gives me all senders and all implementers of a particular method and the same applies to classes and symbols. Symbols are often send as messages consisting de facto of data (look for "perform:").

These are the main reasons why am implementing JavaScript in Smalltalk code, because I really don't feel like searching in text files, fighting with bracket closures and all the same mess that exists in C and C++.

[tomim]

Dynamic translation by Google Translation Service API
Just forget about that! I have never yet come about any translation service, which would work. The translations supplied are ridiculous at best!


It's not point in the Google Translation Service. Project is evolved from 1st version which was based only on that service.
The whole idea is to dynamicaly load text replacements from as you say "some concrete and well prepared translation".

I think you have superficially read main post ...http://extjs.com/forum/showthread.php?t=72978
Please read my last post on that page where second paragraph tells about text recognition. And later on the whole point.

Understanding of ExtJs Object creation and it's relation to config object's ,how and when they are applied is needed
to understand why symbols are not universal solution in web application development with ExtJs.
To fully support symbols, complete ExtJs should be rewritten. Especially getters and setters.

Anyway, I wish you luck to implement symbol only version.




From your name I assume that he are from the Serbo-Croatian language area and this is a part of the world where dialects are very important. From my friends in Beograd I heard not too long ago that this one language "Serbo-Croatian" (leaving all politics aside) is currently starting to drift apart for political reasons, because people in the countries where this is spoken are inventing new words to distinguish from their neighbours (merely because of politics). How could such things ever be handled by a software!?


P.S. There is no Serbo-Croatian language. Serbian is in cyrilic and Croatian is latinic. And no, there is no word inventions. Someone trick you wery well. :D:D:D Our languages are similar as German and Austrian but not the same. Put aside latin/cyrilic difference.

[TheBerliner]

Dobre dan Tomislav,

Unfortunately, my knowledge of EXT JS and JavaScript is not a good enough to fully understand what is going on when reading your code examples.

In your posts I find a lot of subjects discussed, which in my view are not needed or would even disturb the simple and straightforward translation procedure, which I have described in the post above.

My question therefore, is it correct that instead of placing concrete texts into the setter methods of text fields, one would store some kind of text keys (I proposed special strings called symbols) into the configuration and setter methods, which are then replaced by the corresponding text in the selected language prior to being rendered?

I see this as the only viable way, also because otherwise one would still store some concrete text inside the code, and that is always the worst solution of all. There may never be any user visible text inside the code!

Thank you for a short explanation to a JavaScript newbie.


P.S. There is no Serbo-Croatian language. Serbian is in cyrilic and Croatian is latinic. And no, there is no word inventions. Someone trick you wery well. :D:D:D Our languages are similar as German and Austrian but not the same. Put aside latin/cyrilic difference.

1) Seems you have never been to Serbia where >95% of all Serbo-Croatian language is written in Latin!!! Cyrillic is only used in official papers. I lived there recently for 1,5 years. But Politics make many people belief in square circles.
2) Even 3 Crotations who are married in Serbia confirmed the 99,5% identity of this one language. But if you consider every dialect to a be a language, then you have hundreds on the Balkan.
3) The only difference between Germans and Austrians is their one common (and 100% identical) language. An old proverb.

[tomim]

Guten abend :)


Dobre dan Tomislav,

My question therefore, is it correct that instead of placing concrete texts into the setter methods of text fields, one would store some kind of text keys (I proposed special strings called symbols) into the configuration and setter methods, which are then replaced by the corresponding text in the selected language prior to being rendered?

I see this as the only viable way, also because otherwise one would still store some concrete text inside the code, and that is always the worst solution of all. There may never be any user visible text inside the code!


Having symbols instead of texts is a good point. But in web applications you usually have many dynamic parts.
There are cases when they are very usable, but sometimes they are burden to the development process.

I don't have that long working experience as you but I have been working last 10yrs. with AS/400 (RPG, Synon 2E), UNISYS( COBOL 2yrs.), Win platform ,Java etc. So by my point of experience I could write many examples of positive (old platforms) and negative reasons ( ExtJs especially) of using symbols.

(following part is about web applications, especially for ExtJs )
Let's say you have a form with fields which are dynamically generated depending on some user interactions or field labels that are changed dynamically. In banking software you could have web form showing different input fields depending on different client statuses, sometimes field names can have labels generated by client data.

How would you easily link that with symbols?How would you now what component will have which symbol for which object property?
Dont forget, they are dinamicaly generated. You could do that in browser or in server side, depending on design and demands of application. If you are considering universal solution then you must think on any possible case.

I am not saying it is not possible. Off course it is. But my personal opinion is that it is easier without symbols in that specific case. To enable translation to existing aplications as easily as possible what I will choose? Text instead symbols. Reason is obvious.

I would rather not to mix a little bit of symbols and a little bit of text values. I will rather stick to one of them. As I have a case similar to previous example, I will rather use text values. It will save me a lot of time.

Even better, for example grid with different data structure depending on user selection. In this particular case you have to have different column names which also can be dynamically created. Column names from table column name can not be always used as display name on your grid. Linking symbols to translation texts will complicate things even more.

How would I do that easily with symbols? Again, how would you now what component will have which symbol for which object property?

Especially without additional programming effort and additional time I will spent?

For example, company I work for have two database tables, one for ordinal client data - physical person,and one table for legal person - company, GMBH :) or some. They contain different columns but they are shown in the same grid depending what user selects.

If you would like to have absolutely dynamic grid I think that using symbols will be much harder to implement if not impossible.

And why should I have dynamic grid at all?
Well, this is completely another story related to idea about how ExtJs , WEB 2.0 / 3.0 and AJAX is working all together. It is matter of design approach.

There is something I have seen in some Visual Basic and C/C++ applications not supporting my OS language (when using symbols ). For example installing software. Then I have seen something like "{0}...{1}?" so decifer what it means?
Also similar thing I have seen on AS/400 when using different language than SYSVAL. If program cannot find MSGFILE or it does not exist for specific language you will have a screen with a lot of question marks (if you are lucky).

In any case web based front end should not be linked (let say be dependent on changes in backend). Or better to say to be less dependent as possible.
Idea is to make as less as possible needed changes in web frontend to support new changes in backed.

In some cases it is better with symbols and sometimes it is better with pure text values. Depending on the case. I think there is no definitive answer.



I must answer you to this, because it is related to software internationalization. And yes, it is very good example.



1) Seems you have never been to Serbia where >95% of all Serbo-Croatian language is written in Latin!!! Cyrillic is only used in official papers. I lived there recently for 1,5 years. But Politics make many people belief in square circles.
2) Even 3 Crotations who are married in Serbia confirmed the 99,5% identity of this one language. But if you consider every dialect to a be a language, then you have hundreds on the Balkan.
3) The only difference between Germans and Austrians is their one common (and 100% identical) language. An old proverb.


1) Yes I was. About 25yrs ago. Please, there is no Serbo-Croatian language. Serbian or Croatian. With that statement you could insult Croats or Serbs. It is the same as I say you are speaking Swedish as it also belongs to germanic languages. For example ,see this link http://en.wikipedia.org/wiki/Germanic_languages.With this having in mind I may say you are speaking Swedish?! :) Or that German is dialect of Swedish?!This will probably insult you but offcourse this is not my intention. Your language is your identitiy and your heritage.

2) Good point. Dialect. Why we have Canadaian and French and Suiss on language selections in manny apps? British english and American and Australian english? After all I understand russian, polish, slovenian, ukranian, bulgaruan as all they are slavenic languages and many words are very similar. Maybe world will be better if we all speak one language. Then I will choose english as most people speak english :).

3) OK. You probably know this better than me, but also I have worked with some Austrian companies. Some good frends from there I have. They also told me that German and Austrian are similar but different. Maybe we are speking about dialect.I don't know german to tell. Isn't this very similar to your statement in 2)?

In any case, point in internationalization is to support translation for some country/nation. And Croatian and Serbian are different nations as German and Austrian are.No matter are they are speaking just different dialect or belongs to the same language group.

Mit besten Grüßen,
Tom

[tomim]

Hello Tomislav,

Dynamic translation by Google Translation Service API
Just forget about that! I have never yet come about any translation service, which would work. The translations supplied are ridiculous at best!

Yes they are. But we are translating GUI wich mostly have one or two words for label, title etc. If this can speed up and help with translation then it is ok. We will not translate essays.

Many times happened to me to translate something to english and I cannot recall the word in english. If I get a tip I will recall it and correct translation if needed. Doing this "semiautomatically" will sometimes speedup my translation. This is the reason I keep Google Translation Service. Is it realy nedeed? NO .

Regards,
Tom

[TheBerliner]

Hello Tomislav,

First of all, thank you very much for the long reply. I will respond to this with my thoughts and comments (again dictated by voice recognition, therefore probably not bug free)

First of all, nothing is absolute (except, following Einstein, the stupidity of mankind [or was it the only thing that is endless?]), therefore the existence of a couple of exceptions is not sufficient, at least in my eyes, to make a successful recipe inadequate.

Symbols are not a matter of old or new languages but rather of delegating things to where they belong, and a concrete, language dependant text never belongs in the code. It should be stored in some kind of file so that it can be easily replaced without affecting the code itself. Placing text into the code is a mistake often made by Anglo-Saxons who expect the majority of people to accept their English language (de facto a language imperialism). Such mistakes should not be made by Europeans who know too well about the importance of languages.

In the great majority of cases, a data field has some name and essentially this name is the text key symbol. There are exceptions to this rule for example when concrete texts of different sizes are needed for different places where the same field is used. For example, a table column is often shorter than the label of an entry field. This is simple to achieve by just using two slightly different symbols for the different occasions of presenting this same field.

In my applications, a user can create his own data fields and add them to every data object (such as customer, product etc). This is exactly the case that you're describing. We asked the user for a field name, which is different from the visible label. If the user fails to supply a field name, the software issues an artificially created unique field name and add it to the field. The user also enters his field label and this is linked to the field name (symbol) and stored in the user modifiable part of the translation database (which really is just a dictionary file for performance reasons).

So with this I hope to have given you a concrete example how this assumed problem is not a problem.

If I understand you correctly, you want to continue storing concrete language text (let's say of the primary language) into the code and then somehow translate this into the requested user interface language?

If that is your idea, I beg your pardon, but this is - friendly said -a very very bad idea and a very cumbersome concept. And there are many reasons for this statement. I would under no circumstances implement such a solution. Never ever!

When I wrote my first thoughts and comments, I wanted to give you some input to make your work easier and at that time I had not yet read your details on the Google code page from where I gained the impression that you were going into a wrong direction (in my definition).

Just to give you a couple of arguments for my point of view:

Symbols are better, because the external representation of text even in the primary language may change. In the case of symbols, this never affects the program code, because all changes are made outside the code.

Symbols are better, because you can offer the user to modify any external representation of text, which will never affect the program code. Like this, the software can merge a user specified (or modified) translation table into the standard table and override the standard translations. Like this, a user or system administrator can partially or completely individualise the user interface texts of the application.

Symbols are better, because the translations can be handled by specialists in something very simple like an Excel sheet. The content of this Excel sheet can be used to create the runtime dictionary. Programmers are anyway never good in writing user interface texts that the user can really understand.

Symbols are better, because with a simple parser one can scan the program code and detect all language symbols. Please refer to my earlier post where I gave examples of a stringent syntax, which we have been using (actually in all of my projects over the last 25 years). This simple and astringent syntax allows to extract all text keys automatically from the program code. (In Smalltalk this is even simpler but that is another story).

Concerning your example with the private and the company table I don't see your problem. As I stated before, it often makes sense to use different visible texts and therefore different text key symbols for different forms (views) of presenting this same data field. This is much easier when using symbols. All that is needed, as one of several examples, is to automatically change the prefix of the text symbol to one that is only used in grids. Please refer to my earlier explanation of the syntax of the text keys, where every text key has a prefix, which symbolises its form of usage.

A practical example: A button has typically less space to show text compared to a menu item. Therefore, although the function may be absolutely identical, we always use different text keys (symbols) for buttons, which typically just differ by one character from their equivalent symbol, which is used for the menu item with this same functionality. All that is needed is a different prefix (the first character of the symbol before the underscore).

As a resume, I really don't understand where you see the problem. Additionally, in my view implementing my proposal should be a lot simpler than what you seem to be doing currently (although I don't completely understand this, I have to admit).

Again: all that is needed is replacing the symbol with the concrete text prior to initialising the text property of the newly created user interface elements. There should only be a few setter methods, which do this, and these must be enhanced by adding a function call, which checks the string if it is a symbol and which replaces the symbol by the appropriate text value, if required.

Like this, one could even use a hybrid form of mixing symbols with text keys (which I would not find good, but which might help others in the migration process).

In case that your interested, I should be glad to call you by Skype or on some landline to discuss technical details personally. Just send me a PM how I can contact you.

Regarding the last subject of the languages, I don't want to extend this discussion, because I see that it is highly influenced by politics (especially on the Balkan). I have lived in eight European countries, I have run my own companies in five and made business in more than 15 countries. Over the last 10 years I have been living in former Habsburg countries, in Slovakia, in Zemun and elsewhere.

Unfortunately, due to the very negative US influence on Europe, we live in an age where nationalism is growing again especially within the countries under former Soviet influence (and the same is true for Ex-Yugoslavia). And nationalism is never good no matter where. Within the German language countries, there are six to eight partially strong dialects but they are all based on absolutely the same language. If anybody says something else, it is merely politics and politics rarely reflect reality. The strongest dialects exist in Switzerland where sometimes one doesn't fully understand the people from just a few kilometres away. But still, all those dialects are considered to be variants of the one and same language.

If it makes you happy, regard Croatian and Serbian as different regardless of how minimal the differences really are. But please allow me to doubt your words as you have made the statement that Serbian is written in Cyrillic, which simply isn't true and I know that all too well from my own experience in Zemun. All that was in Cyrillic were the bills for electricity, telephone and from the financial office and most of the older street names. Everything else and absolutely all business correspondence is in Latin.

So let's close this Balkan language subject and stick to the working part. And to finally grand credit to your Croatian identity I have to state that you have the most beautiful parts of former Yugoslavia (except Piran in Slovenia, which is also extremely beautiful, the nicest Italian fisher village I've ever seen).

Greetings to the Balkan

[tomim]

Dear sir,

In replay to your post on this forum and private message to me...

I never mentoned anything against Serbia and serbs. You point it out on the forum and forced me to replay as you made very wrong assumptions
misleading other readers (if there is any at all reading this) and you turned this into something not belonging to this forum and topic at all.

I don't understand where do you get idea about my bad impressions about them?! (from private message you sent to me)
It seems to me you don't understand many things about this issue.

After all I have a couple of great serbian frends.

By the way, Zemun is in Vojvodina, autonomn republic as Kosovo was. There is no or little cyrilic in those areas.
50% people living in Vojvodina are no serbs but hungarians, croats, bulgarians, romanian. Just like most of Kosovo are albanians.
http://en.wikipedia.org/wiki/Vojvodina
Every else in serbia mostly used is cyrilic. Most news papers are in cyrilic, movie titles are cyrilic. (I can catch their tv signal)
And something considered as official language is legaly language of that country also as cyrilic letters are.

The same thing is for Bosnia in areas where are mostly serbs. Everything is on cyrilic. I have oportunity to travel trough whole Bosnian teritory. In serbian shop centers in Bosnia, there is almost everything on cyrilic. Road tables with town names are on cyrilic. Even flags on state oficcess are serbian flag, not Bosnian. Lucky for me to know how to read cyrilic, else I will be lost there.

As I gacefully ask you not to mix sebo-croatian with serbian or croatian and you is still using this. It sounds to me as a intentional provocation.
This serbo-croatian and croato-serbian are texts written on school handbooks of literacy and grammar in former exYu.
It was one of many inventions of komunists to spread false brotherhood and unity. But that was stop to exist about 20yrs ago.
After Yugoslava goes appart, for some reason in serbia many not enough educated people is still using this term but generaly it has no any meaning at all. Intelectuals and educated people in serbia will never say they are speaking serbo-croatian.
Saying that they speak serbo-croatian is like you are saying they were give up from their identity and heritage.

Croats and serbs has nothing in common because of different mentality, culture, religion, letters they use, gramatical rules...just name it.

I don't see bad US influence. If there were no US that crapy war will last much longer. Germany was also one of the first who tried to help to finnish this war a soon as possible.And I am very grateful for that.

I agree thet there is no point to talk about this any more as me or anyone else nationality has nothing with this forum and topic. But if you say so, then please don't send me a private messages related to this issue any more. So I will not respond and comment here or on private messages any more.


I am on this forum for reasnons related to ExtJs and it should stay that way.

In any case if you found plugin I wrote intersting to you ,you are entitled to use it and change it to your needs. I have made this in my free time as also I give you some of my free time and answer to some of you questions and also tried to help you understand
some pointed wrong assumptions not related to this forum at all.

Wish you best luck in further lerning of ExtJS. When you learn ExtJs enough, I hope you will find the way how to implement symbols instead of making a filosophy from that.

Tom

[danh2000]

@tomim

Please don't waste your breath - this has been winding people up and trying to pick a fight ever since he got here.

He has no idea how to communicate with people and spouts the rest of that rubbish in an attempt to cover up his inadequacies as a developer.

He obviously leads a very sad and friendless life!