Feature Suggestion for v3.3: previous language

[picasso]

If you added addLanguageSwitchListener to simplify the integration then it will be also very useful to have some variable or function to know previous language or language before tab switch.
In my integration I use addLanguageSwitchListener but I need to know from which language was the switch so to be able to copy or update the field for the active language.

[johnclause]

Right, I already realized that addLanguageSwitchListener is not enough. The latest .5 version has two other hooks addLanguageSwitchSaveListener and addLanguageSwitchLoadListener - long, but descriptive names, if you have better naming suggestions, let me know.

'Save' runs before the switch and this is where you are supposed to save your custom edits to the original field. Then q-X takes what you saved and copies it to a proper place. Then it replaces original fields with a new language data. Then 'Load' is called, where you are supposed to do your tricks to load the data from the original field to your own environment.

This way you do not need to know the language, neither before, nor after.

I am trying to design in in the way, that integrators, would not need to know any details of how q-X works, and they should not use any internal variables of q-X, because those are always subject to change. You should only deal with with your own stuff and an original field, just like you would do without q-X at all. You always need a way to update original field, and you always need a way to load original field to your editing element, and that is the only things needed to be called inside Save and Load. Those are also the things, which q-X has no way to know, which is why integration is needed.

If you really need language, there is variable qTranslateConfig.activeLanguage, which is set to previous language during 'Save' action and is set to the next language during 'Load' action.

Do you think this design is flexible and robust enough? How would you design it so that we would never have to change it again, even if the internal implementation of q-X is changed?

[johnclause]

Actually, instead of using internal variable qTranslateConfig.activeLanguage, use function qTranslateConfig.qtx.getActiveLanguage(), if you really need to know language.

Also, I would be curious to know the details of your case, why do you need to know language, because I cannot imagine such a case. Could you describe it?

[johnclause]

It all changes so quickly, that I do not remember all the details myself. I am working on integration documentation now. In fact, 'Save' and 'Load' actions are called with one argument, language code, so you do not need to call getActiveLanguage(), you already have language code from the argument inside those functions. But again, it is provided just in case, but should not be needed in most of the cases.

[picasso]

addLanguageSwitchSaveListener and addLanguageSwitchLoadListener - long, but descriptive names, if you have better naming suggestions, let me know.

I suggest to call them addLanguageSwitchBeforeListener and addLanguageSwitchAfterListener.
From my point of the view it will be more abstract and more clear. What If I do not need to load something or to save? I just need to know that now language will be switched or it was switched already.
One more argument is that the concept of Before and After callbacks is very common and will be easy to understand.

Do you think this design is flexible and robust enough? How would you design it so that we would never have to change it again, even if the internal implementation of q-X is changed?

I think with these 2 new callbacks (before and after) it will be easy to implement almost any type of integration.
In my case I would prefer to have 2 arguments in this callbacks (activeLanguage and languageToBecomeActive). Because in this case I will be able to implement my integration just in one function. Without it I need to use both of the callbacks and save previous field content in internal var.
But your implementation is certainly simpler and because of it more clear and robust. It's just my opinion.

Actually, instead of using internal variable qTranslateConfig.activeLanguage, use function qTranslateConfig.qtx.getActiveLanguage(), if you really need to know language.

I also suggest you to create a function to get language name... for example something like qTranslateConfig.qtx.getActiveLanguageName()

because now I have to use your internal array 'language_name' to display language name on UI elements.

Also, I would be curious to know the details of your case, why do you need to know language, because I cannot imagine such a case. Could you describe it?

I just need to initialize the filed if it's empty based on data entered for another language. My idea was to learn theprevious language and then get the data from your hidden field. But your implementation will let me do the same more easily - I just copy data from original filed in 'before' callback. In this case I do not need to know the structure and names of QTX fields. It's certainly more robust.

[johnclause]

Dmitry, I followed your advices and added arguments and renamed functions in the latest .8, which you are already testing. Please, let me know if this works for you in a complete way, before I start advertising these method for everybody. Once we do that we should never change the names of interface functions anymore.

Oops, I forgot about getActiveLanguageName(), will add it on next update.

Anything else? I am thinking that plugin like Visual Composer may need to disable Language Switching Buttons (LSB) temporarily to prevent from switching when they open their auxiliary window. So, we may add 'disableLSB()' and 'enableLSB()', or lsbEnable() and lsbDisable(), which naming do you like better? Anything else you may think of?

[picasso]

Thanks, John!

the new callbacks work wonderful.

So, we may add 'disableLSB()' and 'enableLSB()', or lsbEnable() and lsbDisable(), which naming do you like better?

I prefer more descriptive names... If I do not know what LSB means - I should read the documentation :)
My variants: enableLanguageButtons(), disableLanguageButtons()

Anything else you may think of?

Concerning additional improvements for integration. I think you need to add:

• getEnabledLanguages() - for example I need it to create a button "Copy from English". I think that you can combine all information about available languages in one structure - id, name, flag. In this case we do not need getActiveLanguageName(). In my example this function could return:

{"en" : { flag: "gb.png", name: "English"}, "ru" :  { flag: "ru.png", name:     "Русский"} }

• getFieldContentForLanguage(field, lang) - to make an abstract layer to get data from some field for specified language
• putFieldContentForLanguage(field, lang) - to make an abstract layer to put data in some field for specified language (you can use 'load' and 'save' verbs if you think it's more appropriate)

After that QTX will be ready for almost any type of integration.

[johnclause]

So, I made so far (in 3.2.9.9.0) getLanguages, getFlagLocation, isLanguageEnabled, addLanguageSwitchBeforeListener, addLanguageSwitchAfterListener, enableLanguageSwitchingButtons. Should be enough for your purpose, is that ok? Any other ideas?

[picasso]

Thanks, John! I will try it.
But I'm a little bit confused with the description of 3.2.9.8.9 -

cancelled previously changed at 3.2.9.8.8

what was canceled? it's not connected with my problem of POST array?

[johnclause]

No, it is unrelated to POST, it is only for that one item.

[picasso]

Ok, thanks. Then I will try the new release.

[johnclause]

This is probably ready to be closed? We can still write into a closed issue and may re-open it if needed.