We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 36754
    • 21 Posts
    Hello,

    I am a beginner with modx (revolution) but had an interesting look around. Managed to compose quite a complex site though.

    Title says it. To be more precise, in one case I am using pdfbridge but have also a multilingual setup with different contexts and different (sub)domains. using lexicon entries that should grab the current language from the context-settings in the pdf-template ends up with kind-of random language output (by the way: why is that?). $modx->context->get('key') throws "mgr". how do I get the context of the _page_ I am currently editing? Or is there any other decent way to internationalize in the manager context according to editing pages from different contexts?

    thank you very much for any help.

    This question has been answered by BobRay. See the first response.

    • discuss.answer
      • 3749
      • 24,544 Posts
      The context of the page should be available with this (depending on which event you're tied to).:

      $resource->get('context_key');


      I'm not sure if it will be available early enough to control the language used in the Create/Edit Resource panel or not. You might try something like this:

      $modx->setOption('manager_language', 'en');


        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
        • 36754
        • 21 Posts
        Thank you BobRay,

        $resource->get('context_key');

        gives me at least the name of the relevant context, from which I can draw conclusions about the associated language with tht page (of my multilanguage/-context site) and retrieve the right translation from the lexicon.

        thank you,
        ~d
        • Keep in mind that the resource object is only available during relevant events. It's there if your plugin fires on the various resource-related events, but not there if your plugin fires on other events, so it's always good to test to see if the object is empty just in case your plugin is tied (either purposely or erroneously) to other events.