Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter 1name

    (@1name)

    Thanks for your reply, @dcooney!

    I tried to use the alm_query_args filter, but setting $args['lang'] = 'en' or $args['language'] = 'en' both didn’t change the output to English – not even after I added the code from the support forum thread you linked above to my child theme’s functions.php (if this is where this kind of code would go..)

    Furthermore, when inspecting using Firefox’ built-in function, the AJAX query’s argument for lang still appeared as empty, despite the new id argument showing up correctly. When I tried setting $args['language'] no language argument showed up in this view at all, the empty lang argument remained.

    HOWEVER!
    When I manipulate the AJAX query by myself and set an argument language=en, the JSON reply appears to be partly English: see here.
    The links to the single entries are now to the respective English versions (/en/ in URL), but article title and text, translated by Sublanguage, as well as the meta-labels, translated using __() are still in German.

    Any ideas? 😀

    Thanks a lot for your effort and interest!

    Thread Starter 1name

    (@1name)

    Hi @dcooney,

    thanks for your reply!

    Unfortunately, I couldn’t find any info on how Sublanguage deals with custom queries. I don’t know what exactely to look for, maybe you’re more successful than I was browsing the plugin’s Git repo. It does say something about the case:

    If you need to access data through AJAX, you just need to add the wanted language slug into the ajax request […]

    but having no knowledge of JavaScript, I didn’t understand most of what came afterwards.

    I found quite a few discussions dealing with issues concerning ALM and Polylang or WPML, which mostly concluded with setting the lang parameter in the call to ajax-admin.php. I tried to play around with it a little but got no result – literally, nothing changed, no matter if it was set to en, en-US or en_US :/ I also tried setting it using the global $sublanguage variable, as proposed in the plugin’s readme. This one should also be available through JS

    However, if I changed the site’s language (from the admin panel’s settings) to English, so did the content loaded by ALM.

    If it is any help: I am currently testing the setup here. As you can see, the URL contains /en/ and menu and tab tags are loaded in English.

    get_bloginfo('language') shows the correct value. I am querying it to determine which widget shall be displayed.

    Thanks again for your reply and any further help you can provide 🙂

    Thread Starter 1name

    (@1name)

    Okay, after some hard-to-find-out differences between the current ACF free and premium versions, I was able to define the custom field groups “myself” in my site-specific plugin. This made it possible to declare the labels ready for localization, using the __() function 🙂 Using Loco, I could then create a translation file and add the translations of the respective strings quite easily.

    The only thing, that is still giving me problems, are the strings of checkbox values – which I haven’t been able to translate effectively so far. I could enter translations for them in Loco, but the original strings are displayed when I switch language. I don’t think that this is possible with Sublanguage either, is it?

    Another problem that is even less related to Sublanguage but maybe interesting to any future readers of this thread: Now that I moved the ACF field group creation to my own site-specific plugin, they are not accessible from the ACF UI in the admin panel anymore. This might be problematic if you’re about to set up custom fields for someone else who should be able to change them later on.

    Thanks a lot for your help, Maxime! 🙂

    • This reply was modified 8 years, 1 month ago by 1name. Reason: marked as resolved :)
    Thread Starter 1name

    (@1name)

    Hey Maxime,

    thanks for your quick reply!
    This sounds like a way better idea, but I can’t quite figure out yet how to implement it. I read through some l10n/i18n WP documentation but am still unsure, because the strings that I need to be translated are most likely not within any provided translation file.

    I’m totally new to the entire gettext/l10n/i18n topic, so I don’t know if I got this correctly but what I’m thinking about now is that I need to create my own .po/.mo files which have the few strings I am using plus my own translations of them, and then, in the respective function in my site-specific plugin, I call
    __($field['label'], 'my-text-domain')
    and WP will retrieve a string according to the language the user selected in the Sublanguage widget?

    Is this correct? 🙂

    Edit: I am, furthermore, not sure if the approach we are talking about here is directly related to Sublanguage and should be in this forum. If so, I am sorry for occupying your time. If you don’t want to spend any more of it on helping me with my probably off-topic issue, feel free to tell me and I will move my question to stackexchange 🙂

    • This reply was modified 8 years, 1 month ago by 1name.
    • This reply was modified 8 years, 1 month ago by 1name.
    • This reply was modified 8 years, 1 month ago by 1name.
    Thread Starter 1name

    (@1name)

    Oh I just noticed that Sublanguage added a “Language Options” entry to the ACF admin menu, pointing to wp-admin/acf_language_option, which unfortunately is a dead link and breaks the standard ACF landing page as well :/

    Does this mean that what I require is already part of Sublanguage, only I need to fix this dead page issue? 🙂

    • This reply was modified 8 years, 1 month ago by 1name.
Viewing 5 replies - 1 through 5 (of 5 total)