Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not detecting translation keys #95

Open
mehradrishty opened this issue Jan 11, 2021 · 6 comments
Open

Not detecting translation keys #95

mehradrishty opened this issue Jan 11, 2021 · 6 comments

Comments

@mehradrishty
Copy link

mehradrishty commented Jan 11, 2021

I have enabled this plugin in iDE. The problem is our namespaces are different from the file names eg. Our folder structure is like

-src
-assets
-locales
-app_en.json
-app_de.json

Here my namespace is app. So in the plugin configuration when i input " app " as default namespace . My plugin does not work and tries to create file as app.json for the translations.

Can anybody help me how i can configure the plugin in my case.

@nyavro
Copy link
Owner

nyavro commented Feb 14, 2021

Hey,
what internationalization library do you use? How do your keys look like?
i18next requires language specific translations to reside in language folders like en/app.json, de/app.json.
In case, when app is default namespace, keys look like: i18n.t('root.key1');
In case, when app is not a default namespace, keys look like: i18n.t('app:root.key1');
In another supported framework, vue-i18n all translations reside in files by language(similiar to your case), like assets/en-US.json, assets/de-DE.json
Could you provide more details about your set up?

@plehnen
Copy link

plehnen commented Feb 27, 2021

I have a similar problem.
I can't get the plugin to detect my keyfiles.

Backend is Java and the i18n files are in "D:\Work\projectname\Server\src\main\resources\locale" in the subfolders "de" and "en". Inside are several json files (common.json, auth.json, payment.json, ...) with the usual key value pairs.

Frontend is Vue and the files aren't loaded directly but within a REST response which is then injected into the i18n plugin. (I can't load them directly because they get merged with another remote file which can potentionally overwrite stuff, and we also only provide translations for pages where the user has access permissions).

Regardless how I set the path in "Vue locales directory", the code occurences (e.g. {{ $t('common.close') }}) are marked yellow, indicating an "unresolved key".

I've tried relative and absolute paths, including the "de" folder and without. And I also added all filenames to "Default namespace" without any success. Am I using this incorrectly?

@nyavro
Copy link
Owner

nyavro commented Feb 28, 2021

Hi
Looks like the plugin won't work with your configuration. Here is the typical translations folder structure:

...
  -locale
     en-US.json
     de-DE.json

As far as I see, your structure is like:

...
  -locale
     -en
          common.json
          auth.json
          ...
     -de
          common.json
          auth.json
          ...

Here some points not clear to me: how does your translation keys gets resolved? Looks like key 'common.close' will try to get resolved by looking inside common.json, right? Maybe your intermediate REST merges all files common.json, auth, payment into one with correspondent root?

@plehnen
Copy link

plehnen commented Feb 28, 2021

Yes, the structure is correct. I initially load only a few basic message keys (in case the server won't respond) and after the REST response I call mergeLocaleMessage for each key of messages:

{
  "messages": {
    "de": {
      "common": {
        "close": "Close",
        ...
      },
      ...
    }
  },
  ...
}

(Actually it's even more complicated: We only return the messages relevant for the current selected language and active module, and the other modules and languages are loaded in a seperate request to optimize page loading speed)

It's been so long since we have this setup, that I wasn't aware that the files are usually in a different structure.
I guess the best solution would be to change our setup to a matching structure like the "typical translation folder structure" you mentioned. But the files are quite large and as I said will only be returned for modules which the user has access permissions. It's also possible to remotely overwrite some texts of individual modules by different partners.
So I guess we have quite a special requirement ;)

It just wouldn't be so convenient to have all modules inside one big file, and I can immagine situations where others may also want to load modules in a lazy way?

One questions remains: How is the correct format of the "Vue locales directory" for the IntelliJ Idea plugin settings? Is it absolute? Or starting from root? With "./" in the beginning? With trailing slash? This is unclear from the documentation.

@nyavro
Copy link
Owner

nyavro commented Feb 28, 2021

Vue locales directory accepts just folder name, for example above it would be 'locale' - plugin will consider any 'locale' directory as a translation sources root, then it will try to find json files under this folder.
I'll check i18n-vue documentation about how to split huge translation files into smaller ones, maybe there is some way to do it.
I would implement some configuration option to make the plugin work for your setup - I don't think it is hard to do. Maybe it is possible to find some general interpretation of this option and possible make wider use of it.
I still not sure about your setup. Could you share with me the whole project, or it is too secret? :)
Another option - you could create very simple demo project (like several projects in examples directory of i18nPlugin) - no need to make it even buildable and working. I just want to see the examples of translation files, I want to see translation keys structure there and I want to see as much different examples of translation keys usage in vue/js code.

@plehnen
Copy link

plehnen commented Mar 1, 2021

Sure.. I provided you some information via email.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants