Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Suggestion for v3.3: previous language #128

Closed
picasso opened this Issue Apr 10, 2015 · 11 comments

Comments

Projects
None yet
2 participants
@picasso
Copy link

picasso commented Apr 10, 2015

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

This comment has been minimized.

Copy link
Member

johnclause commented Apr 10, 2015

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

This comment has been minimized.

Copy link
Member

johnclause commented Apr 10, 2015

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

This comment has been minimized.

Copy link
Member

johnclause commented Apr 10, 2015

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

This comment has been minimized.

Copy link
Author

picasso commented Apr 11, 2015

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

This comment has been minimized.

Copy link
Member

johnclause commented Apr 11, 2015

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

This comment has been minimized.

Copy link
Author

picasso commented Apr 12, 2015

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

This comment has been minimized.

Copy link
Member

johnclause commented Apr 13, 2015

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

This comment has been minimized.

Copy link
Author

picasso commented Apr 14, 2015

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

This comment has been minimized.

Copy link
Member

johnclause commented Apr 14, 2015

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

@picasso

This comment has been minimized.

Copy link
Author

picasso commented Apr 15, 2015

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

@johnclause

This comment has been minimized.

Copy link
Member

johnclause commented Apr 30, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.