jotomas
Forum Replies Created
-
Posts
-
Hi Kiran,
Oooooopss! I feel really stupid! I have been doing the same for a lot of strings since years ago!
Thank you very much for your patience!
Best regards.
Hi Kiran,
Thank you very much for your response.
The issue with the translations of the GD CPT name “Activitats” seems to have been resolved. Now it shows correctly translated in all languages in the GD Search Box and in WP Dashboard – Appearance – Menus – GD Endpoints – CPT Archives.
May I know which was the problem?
Thank you very much once again for your help.
Best regards.
This reply has been marked as private.Hi Kiran,
Thank you very much for your reply.
The correct strings for “Activitats” in translated languages are the following:
CA : Activitats
SQ : Not used (language configured only to allow changing language of strings)
EN : Activities
FR : Activités
ES : ActividadesI also enclosed four screenshots:
a) WPML String Translation page for “Activitats” GD CPT. The string has been found only three times, none under gd, gd addons or userswp domains. All of them have been translated.
b) WPML String Translation page for “Menjar i Beure” GD CPT. The string has been found seven times. Five corresponding to gd, gd addons and userswp domains.
c) WP Dashboard – Appearance – Menus – GD Endpoints – CPT Archives in Main Language CA: String “Activitats” in CA is correctly shown, as it does in the GD Search box in the Main Language CA.
d) WP Dashboard – Appearance – Menus – GD Endpoints – CPT Archives in Translated Language ES: String “Activitats” shows in CA instead its translation in ES “Actividades”. Same thing happens in the GD Search box in the translated language ES.
I look forward to your news.
Thank you very much once again for your help.
Best regards.
This reply has been marked as private.Hi Naveen,
Thank you very much for your response.
Ninja Forms support solved the issue reinstalling their plugin. I did not think about doing it.
Thank you very much once again for your help.
Best regards.
Hi Guust,
Thank you very much for your reply.
No, I do not translate the CPTs names at WPML > Settings > Multilingual Content Setup > Scroll to “Post Types Translation” like in my image. I have attached the image to show that the specific CPT “Activitats” has been set as translatable and that its slugs have been translated from there.
I have translated the other CPT names from their corresponding page of the link that you enclose https://inforoses.com/wp-admin/admin.php?page=wpml-string-translation%2Fmenu%2Fstring-translation.php&search=activitats#icl-st-toggle-translations
I noticed that, to get the CPT translated names show in the GD Search Box or in the WP Appearance – Menus – GD Endpoints CPT Archives options, the CPT name to be translated should appear in the WPML list of strings under the geodirectory domain, and in the case of CPT “Activitats” is the only in which it does not.
These are the links to other CPTs names strings translations:
I look forward to your news.
Thank you very much once again for your help.
Best regards.
This reply has been marked as private.Hi Alex, hi Guust,
Thank you very much for your replies.
Alex, I believe that the link that you provide is about GD V1 and old WPML versions. I can not find the WPML settings in the link in the current version. Instead, there are “Localization options” (screenshot attached).
Guust, I have set this GD CPT as translatable exactly like all other GD CPTs (screenshot attached).
I can not understand why WPML String Translation finds the strings in GD and GD Custom Posts of the other CPTs but not of this one.
I look forward to your news.
Thank you very much once again for your help.
Best regards.
Hi Kiran,
Thank you very much for your reply.
Ok, I have opened a support ticket with WPML. I will let you know what they say.
Thank you very much once again for your help.
Best regards.
Hi Kiran,
Thank you very much for your reply.
Ok. I see.
I have also added an Activitats listing and now it works fine too.
However, I do not think that this would be the right behaviour. Should not it be showing the archive page in the translated language with the “No listings found” message like it does for the main language, instead showing the home page in the translated language?
I look forward to your news.
Thank you very much once again for your help.
Best regards.
This reply has been marked as private.Hi Kiran,
Thank you very much for your reply.
In fact, I did not notice that for non-logged users the calendars were working fine for all languages.
Anyway, I have cleared caches and I can confirm that now it works fine for admin too.
Thank you very much once again for your help.
Best regards.
Hi again,
I just wanted to let you know that I have gone through the process of checking how much memory eats every plugin by deactivating all of them and reactivating them one by one. I used this handy plugin: UsageDD ( https://wordpress.org/plugins/usagedd/ ).
Definitely the Ninja Forms plugin is the only plugin showing unusual results. Deactivating it reduced the used memory by 300 to 600 M and it was not possible to reactivate it because the fatal error requesting more memory.
Having it active shows memory usage of nearly 900 M in the WP Dashboard and 500 M in the site. Deactivating it reduces both amounts to some 240 M.
I have posted a topic in their WP support forum:
https://wordpress.org/support/topic/huge-amount-of-php-memory-required-to-activate/
Any advice, recommendation or comment would be very welcome.
Maybe it is time to look for another forms plugin to integrate with GD? 🙂
Thank you very much once again for your help.
Best regards.
Hi Kor,
Thank you very much for your reply.
While still investigating about the huge amounts of memory that my site seems to gobble, I would like to ask you what do you think about this part of the error message from Ninja Forms “tried to allocate 335544320 bytes”. Do not you think that it is an absurd amount of memory?
In fact, after having set the PHP Memory Limit to 1024 M and after deactivating and trying to reactivate the Ninja Forms plugin again, I am getting again the Fatal Error message, but the memory amounts specified are even much higher: “Allowed memory size of 1073741824 bytes exhausted (tried to allocate 671088640 bytes)”.
Then, I restored a previously made backup to keep the Ninja Forms plugin activated.
Do you think that it could be Ninja Forms the plugin responsible of this inconceivable memory gobbling?
I know that this is not technically a support question for you, although GD listings Contact and Claim forms rely on this plugin, but I would appreciate very much your opinion and advice.
I look forward to your reply.
Thank you very much once again for your help.
Best regards.
