plugin integration

Yes, this is a good idea, thank you! Please, give us a few days to put that in.

Hi, Franky, could you send me your plugin, so that I can see exactly what you wish? You can use qtranslateteam at g mail d com. Thanks!

P.S. There is “Custom Fields” field which is what you would probably need, but it may not affect your page. That is what I would need to enable for you somehow.

add the language switch buttons to my own plugin

The latest beta version from GitHub: https://github.com/qTranslate-Team/qtranslate-x, which you can download here, has a new experimental option “Custom Pages”. Could you take a look and see if this is what you would want? Please, if you test it, test not only this problem, but rather the whole thing. Thanks a lot.

Hi @franky, please try the latest from GitHub

Integration is in the process of design. Let us do it together. Please, let me know how you envision this.

Right now buttons get at the very top of your page, because, by default, it puts them in front of <form> inside div “wrap”. In your case <form> is located outside of “wrap”, which is unusual, all other admin pages I saw have form inside wrap. So, I created langSwitchWrapAnchor variable, which one can set in a custom script to put buttons wherever desired.

Anyway, there is a lot more to figure out. I saw in some of your pages, in java console, undefined function qtrans_use was used, which should not be. I believe, we need to design integration in such a way, that you would not need any additional coding at all. You would only need to specify ids and classes of items to display or to edit translated per admin page needed. I was thinking about creating an xml-like file, which a plugin/theme developer would have to create to achieve integration. Would this make sense to you?

Could you gather information which ids and classes you wish to make translatable on each of relevant pages?

I realized that currently existent option for custom fields may be in conflict if same id is used on different pages and one of them needs translation, while other does not. I originally thought it would be a rather rare case, but now I see that conflicts are quite possible to happen. So, ids and classes need to be specified per each page separately.

Please, let me know what would make the best sense to you.

Thanks a lot.

Sorry, @franky, for the delay in reply. I am busy right now with something else, but will be back to this shortly.

Meanwhile, a few notes. First of all, you do not need to run any scripts serving language substitution on your own. If you do, please, point me to a line in your code to disable it during my testing. Second, please, gather the information on all your pages and fields needed to be translatable. Like this, for example:

On page /wp-admin/admin.php?page=eme-new_event:
<input type="text" id="title" name="edit-event_name" value="">
<textarea class="wp-editor-area" rows="20" autocomplete="off" cols="40" name="content" id="content"></textarea>
etc.

It easy enough to do with “Inspect Element” action on mouse right-click, but I am not sure which fields to you want.

I will make it work shortly, it all is ready in pieces, it is a matter of putting it together, and I will need the information as described.

Thanks a lot.

P.S. Please, give me your input which format to choose for supplying this information. XML file? JSON file? What else? Which one will be easier for plugin authors to create and to be load quick?

BTW, @franky, I am getting bunch of errors on wp-admin/error_log file:

PHP Notice:  Undefined variable: option_categories in /wp-content/plugins/events-made-easy/eme_widgets.php on line 284

PHP Warning:  Invalid argument supplied for foreach() in /wp-content/plugins/events-made-easy/eme_UI_helpers.php on line 4

PHP Notice:  Undefined variable: option_categories in /wp-content/plugins/events-made-easy/eme_widgets.php on line 136

PHP Notice:  Undefined variable: option_categories in /wp-content/plugins/events-made-easy/eme_widgets.php on line 144

Keep WP_DEBUG on when you develop in order to clean those up.

Any news on new plugin?

I guess I need to repeat the code for $page_config[‘pages’]

Correct. Later I plan to make it all configurable with an xml-like file to record all those things, so that people could put in their own custom configuration without an additional plugin.

I don’t really know if it is the correct method

It is too much of additional coding inside eme plugin and not everyone needs it. We both could share the authority and the support of it. I listed you as an author. I think it is better to keep it separate for those who need it only. Besides, I was thinking that it would be easier for us to tune it this way for the first time, since I do not want to dig and to change your plugin. Let us make it work 100% first, and then we will think about the best way to deploy it.

More than one anchor on a page does not yet work well, since two different sets of buttons do not interact with each other, although each set works ok separately. I would use one set per page for now.

Let me see how far you got, submit pull request with whatever you got even if it is not working well. Then I could comment and improve further.