I18n for guillotine 7 app

Enonic version: 7.14.0

Is there a way to use functions from the i18n lib in guillotine 7.0.1 app?
I can’t get the phrases as the guillotine extensions code runs on the app and don’t have the i18n bundles available. I could put them in a repo, but that defeats the purpose.

Also, there’s a lot of hurdles by migrating from the lib to the app. Why did you you guys choose to make the java upgrade an app, and not a lib?
The hurdles include i18n, permissions, context etc.

Hi, thank you for your report. I investigated this issue and found a bug in XP.

Regarding your question about migration to Java, it allows extending the schema easily. There is a big difference between Lib and App. Lib allows generating a schema per site, while App allows generating one schema globally for all installed applications on your XP instances. In other words, you can work with one GraphQL schema instead of N. This is easy to use and support in production. Of course, sometimes there are challenges to implement some things, but for regular things, it is super easy.

We are not sure what you mean by this.
Do you have specific examples where permissions and context are harder to work with when app-guillotine is in use?

Hi Amund0.

  1. I’m curious. Why would you want to access the i18n functions of the XP framework via the GraphQL API? These things are normally placed in your own front-end. Is it some kind of re-use?
  2. You may extend Guillotine to serve any data, including the property files stored in your app - or even expose similar functions. It is all up to you.

We are using localize when resolving content types in the guillotine extension.
Sure, we could move it to the frontend. But what if we have multiple frontend implementations containing the same content type? It would be so much nicer to have the possibility of resolving content types using localize (as we had pre-guillotine 7)

resolvers: {
  HeadlessCms: {
    getBreadcrumbs: (env) => {
      ...
      return {
        ariaLabel: localize({ key: 'common.breadcrumbs', locale: contentLocale }),
        homeLabel: localize({ key: 'common.home', locale: contentLocale }),
        items: breadcrumbItems,
      }
    }
  }
}

If you will provide the application parameter for localize function it will works correct in this use case.

1 Like

Thanks! :smiley: really appreciate it

Hi Amund,

We’ve just released Guillotine App v7.0.3. Now you will be able to call XP libs in resolvers with correct app context.

For example,

const i18nLib = require('/lib/xp/i18n');

exports.extensions = function (graphQL) {
    return {
        creationCallbacks: {
            Query: function (params) {
                params.addFields({
                    getPhrases: {
                        type: graphQL.Json,
                    },
                });
            }
        },
        resolvers: {
            Query: {
                getPhrases: function (env) {
                    return i18nLib.getPhrases('es', ['i18n/phrases']);
                }
            }
        },
    }
};

Also, in my previous reply I suggested to provide the application argument to localize function. We decided that this argument will be removed in XP8. We created the issue for that.

You must be able to use localize function without this argument in Guillotine extensions starting from version App 7.0.3.

Also, developers can use global variable app directly in resolvers. It was a mistake in the documentation and section Application Context will be removed.

Thank you!

2 Likes