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

Feature: Parent and ignore files #118

Open
1 task done
stewieoO opened this issue Nov 17, 2021 · 12 comments
Open
1 task done

Feature: Parent and ignore files #118

stewieoO opened this issue Nov 17, 2021 · 12 comments

Comments

@stewieoO
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe

So i have an idea but i'm not sure if it's something that is generally desired.

I am currently using ngx-translate and considering a migration to transloco.
However i am missing one feature that is very important to me.

I have my own angular framework with modules and all that neat stuff i reuse in multiple projects.
In that framework i have a default translation file for common resources. (e.g. 'labels.save' -> Save button).
In my project i use a custom translation loader that merges those default files with the loaded language.
CustomTranslationLoader Gist
I made a fork of ngx-translate-extract that takes a path for those default files and an ignore file.
Extract Task

Is that something worth adding to the main repo?

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Describe alternatives you've considered

Currently when i would use for example 'labels.save' as a key anywhere in my application, the extraction would add this key to my language file in the application.
When i now merge the application language file with the default language file in the translation loader, it would override my default value.

Describe alternatives you've considered

Option to provide a parent and ignore file to remove found keys before writing them to the translation file as seen here

Additional context

No response

I would like to make a pull request for this feature

No

@shaharkazaz
Copy link
Collaborator

@stewieoO If I understand correctly you are looking for some sort of "ignore key pattern", did I understand correctly?

@stewieoO
Copy link
Author

@shaharkazaz exactly.
In my example it's keys located in other json files.

@shaharkazaz
Copy link
Collaborator

@stewieoO You are welcome to implement this feature 🙂 I can't say when this might be implemented.

@stewieoO
Copy link
Author

@shaharkazaz Right, that's all i wanted to know really.
If you guys had any big reasons for not adding this. Will do a PR then :)

@shaharkazaz
Copy link
Collaborator

@stewieoO Just to make sure we understand each other, I'm talking about providing a regex/string pattern in the manager's config that when matched the key is ignored by the extractor/detective.
You can give more details about it if you have anything else in mind

@stewieoO
Copy link
Author

@shaharkazaz oh, no. I'm talking about providing paths to files that are structured just like the translation files.

ignore.json

{
  "labels": {
     "name" : "anything",
     "profile" : null
   }
}

Which would result in keys with the same path (labels.name, labels.profile) would not be extracted and written to the corresponding translation files.

@shaharkazaz
Copy link
Collaborator

What's the advantage of providing a file over a regex? seems less flexible and more repetitive.

What do you mean by:

...would not be extracted and written to the corresponding translation files.

@stewieoO
Copy link
Author

@shaharkazaz As i explained in the initial comment, i want to merge translations when the app is loading them
CustomTranslationLoader Gist
For common used translations across multiple apps. So i would want to use those files for both merging them and using them to ignore keys during extraction.

...would not be extracted and written to the corresponding translation files.
The extractor would first look into the specified ignore files (ignore.json in this example) and find the keys labels.name and labels.profile.
Then when it finds those keys somewhere in the app it would not add those keys to the result and they would not be in the translation file.

I can prepare a full example repo (with ngx-translate currently ofc) to demonstrate my usecase if desired.

@shaharkazaz
Copy link
Collaborator

@stewieoO can you make a small reproduction of your use case with Transloco?

@stewieoO
Copy link
Author

@shaharkazaz i'll do that yeah.

@stewieoO
Copy link
Author

stewieoO commented Nov 20, 2021

https://github.com/stewieoO/transloco-whitelist-example
(Unfortunately i couldn't get the assets mapping to work in stackblitz)

The node_modules_assets folder is mapped in the angular.json to the assets folder.
In a real world application this would be something from a library like

{
  "glob": "**/*",
  "input": "./node_modules/@stewie/framework/assets",
  "output": "./assets/"
}

The default-en.json located in node_modules_assets/i18n is what i would want to use to ignore keys with the extractor.

If i would run the extractor over this example, it would write the labels.contentDefault key in my en.json and the transloco pipe would not output the value i have in my en-default.json

@MikeDabrowski
Copy link
Contributor

@stewieoO It's been some time, I hope you managed to resolve your issues already.

I don't fully understand you issue, but maybe you could write custom transloco transpiler that would first try to get translation from lang file and then fallback to the defaults file. That way you could keep files separated without the need for changes in extractor.

@shaharkazaz
I got to this issue while searching solution to my recent problem:
I want to allow my translations team to add keys that would then be picked up by transloco and rendered as a list. So me, as the app dev, wouldn't have to make changes to html files. I did that already but now I got huge entries in 'extra keys'.

So while looking for a solution I found your comment here and it sounds like something that would work for me. I'd be happy to make PR for it, but no sooner than in 2-3months. For now I could make new issue with more detailed description to keep track of it as a feature.

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