monorepo support for shared intl files location

[void-mAlex]

hello, love the definition provider feature
regarding that, was wondering if there was a way to tell the language server that the language files are in a particular folder outside of the ember project.

we have several ember projects (within a monorepo) that share a good chunk of the translations and they are stored in the following structure

• monorepo root; non ember project
  • ember_project_1
  • ember_project_2
  • other_folders
  • node_modules
  • translations
    • route_a.yaml
    • route_b.yaml
    • fr-ca folder
      • route_a.yaml
      • route_b.yaml

without going as far as what is likely a bespoke way of treating the separate languages (within their own folders)
would like to see a way to tell the language server, hey my yaml files are one folder up then look in translations

[lifeart]

I think it may be an option in els configuration, like:

els.local.intl.packageName: translations,
els.local.intl.assetsPath: ./src/langs

where els.local.intl.packageName - name of package with translations [packages?]
and els.local.intl.assetsPath - translations entryfolder for package

also, I see case where we have multiple translation packages like, and in this case, configuration may be relatively complex, I'm not sure we have to support it at this point (I'm trying to figure out options, easy-to configure by vscode)

one more option - have same API with els.local.addons, to specify just entrypoints to yaml/json translations

els.local.intl.translations: "absolute path to translations 1", "absolute path to translations 2", "relative path to translations from project root 3"

(I like last one)

[lifeart]

in addition, we could consider namespace usage from https://ember-intl.github.io/ember-intl/docs/guide/addon-configs

[lifeart]

@void-mAlex are you using 'inputPath' config option for ember-intl to specify translations?

[void-mAlex]

@void-mAlex are you using 'inputPath' config option for ember-intl to specify translations?

we are not for reasons that we don't want them to go through any of the build steps from the cli, but that may be a very good option for others
we explicitly don't want to process or transform our yaml files through any part of the build pipeline as that would result in extra work on the CI for something we wouldn't use (the translations are served dynamically via api calls and have separate pipeline to deal with them)

I guess we could have that set to a value that gets overridden on any builds so they don't actually get processed and only take advantage of the go to definition feature; would take some experimentation but I can see that working

---

as for namespace usage, I think that opens the question on what the path resolution for current syntax;
if I understand the feature (we don't use it) for the audio_player.listen example you could have an

• translations
  • audio_player
    • en-gb.yaml

with the content:
listen: Listen one more time

that would be equivalent to the example from #334 (comment)

I don't believe namespace feature from ember-intl should/would have an impact on the path that els uses to resolve translations

the more I think about it the inputPath makes the most sense as if people already have it set then els just works for them; I'm decently confident that we could make use of it as well
it also seems to cleanly resolve the issue of different projects needing different configs, they can all have their own, as they all declare an ember-intl.js config file

[godric3]

@lifeart Didn't thought I have something to add, but as there are some more topics mentioned in 340 I will try to ;)

• namespaced file support
• custom translation location
• limit for translations to show (5 - 10?)
• kinda "translation" or service, to include it to complete/definition/hover provider to cache tanslation results, and detect > - changes, using Project change file api

1. namepaces and inputPath -> as those are ember-intl configs I think we support both ( not related but we could also look at requiresTranslation and add some warnings... but that's more complicated I think)
   For more custom locations I also like idea of setting with paths to translations, but In case of @void-mAlex we would need also to specify the language like [{'locale':'en-us', file:'path'},{'locale':'fr-ca', file:'path'}] But first I think we should support what ember-intl supports.
2. limit -> you mean to limit number of suggestions for autocomplete, or number of languages displayed for each translation in autocomplete and hovers?
   For the first option: we already limiting all suggestions returned from uELS to 40. I really don't like idea of limiting that even further.
   For second option, yes that make sense, but would be nice to have option to select which languages will be shown(and order?)
3. cache translations and invalidate cache on translation file change -> YES! I didn;t looked much into those topics, but definitely sooner or later I will

[lifeart]

notes about intl support out of the box:

since 'config/ember-intl.js' is js file, we have to write "relatively" smart AST query to extract needed values (if it's defined as bools / strings), I don't think we need to support more complex cases, because "actual" export could be reconfigured, and default values could be used especially for uELS needs.

also, it should fix @void-mAlex case (he could define path to translations, to allow uELS to resolve it, but "owerride" it for export to not process it on build step)

// config/ember-intl.js

module.exports = function (/* environment */) {
  const configDefaults = {
     inputPath: './../node_modules/my-localization/files'
  };

  configDefaults.inputPath = 'undefined';

  return configDefaults;
}

in this case we will follow for first valid inputPath match, and if it's streang, we could count it as value.

or we could execute it, passing "environment" = "development" (as we do now for config/environment.js), and to able to detect "uELS" we could provide some environment variable to nodejs process

also, it solve question by limiting locales, because we will use includeLocales config option

[godric3]

I'm not fan of detecting by position, because i guess someone can have code like inputPath = getCustomInputPath(env) || './../node_modules/my-localization/files' And writing ember-intl config in special way to allow uELS to detect thing is also a bit shady.
On the other hand executing it seems more practical.
If detecting uELS is needed then we could pass uELS as environment?
And use setting for choosing if we want to pass uELS or development as env?

[lifeart]

@godric3 sorry for long delay here #342 created to move forward, I think we could start it :)

[lifeart]

@godric3 some parts implemented in #344