UI Enhancement: Allow Key Creation from the Interface

[JaguarRocka]

Hello 



I really appreciate this gem ! However, for my use, I've noticed that some features are missing. One of them concerns key management.

Currently, to add a key, you have to go through YAML, which can be particularly troublesome when several people are working on the project and discrepancies arise between different files.


I believe it would be much more convenient to manage all translations directly through the interface. For that, it would be useful to be able to create a key via the front end.


To address this need, I have added the necessary routes, as well as the new and create methods accompanied by two corresponding views and one button in index.html.slim


What do you think? I would be delighted to have your feedback on this proposal.

Furthermore, I have other suggestions regarding deletion management and I could work on those if you're interested.

Thank you for your attention and for your excellent work.

Best regards,
Jean

[westonganger]

You should be creating the new keys in your YAML files within your PR where you are going to utilize the new key. Same thing for deleting keys.

Can you explain a workflow where the above statement does not make sense?

[JaguarRocka]

In my company, we manage multiple YAML files for translations (en, fr, nl, de, etc.).

With the current solution, we first need to add the key to the reference YAML file, then import it before being able to use it in the front end. After that, each translation needs to be updated. This process involves multiple steps and increases the risk of errors, such as unintentional overwriting of translations.

With my proposal, the key is created directly in the interface (and therefore in the database) and can be edited immediately. This reduces YAML file manipulations, minimizes the risk of errors, and simplifies the workflow.

[westonganger]

My problem with this is that we run the risk of adding keys that are unused in the application. This is because the Add process is not tied to any particular PR (and things always end up changing during a PRs lifecycle).

Can I suggest a different workflow for your team? When creating a PR you can just create a new YAML file named after your feature name or JIRA ticket number and then use the following format:

# config/locales/some_new_feature.yml

en:
  some_new_key: "foo"
fr:
  some_new_key: "bar"
es:
  some_new_key: "baz"

Whenever releasing a new version of your application or pre-deploy, then you can have a step where all translation files are uploaded to the rails_i18n_manager, have your translator folks double check everything, then export your new files and cleanup all the feature files.

This should ensure that things stay clean and does not break the regular PR process.

Does this make sense?

[westonganger]

We currently allow deletion of inactive keys. So if you have suggestions about deletion please open an issue to discuss that separately.

[JaguarRocka]

I liked the idea of using the GUI to manage all of this and thus limit file imports, but yes, your suggestion of adding a YAML file by PR is relevant. It requires some organization, but why not?

Regarding deletions, I'm facing an issue with the unused key concept. The gem doesn't detect them. I ran a test by including unused keys in my YAML, and they aren't marked as unused and cannot be deleted.

[westonganger]

Let me know how the suggested workflow works for your team. I am creating a PR to add the suggested workflow to the README (#33) but lets iterate on it based on your experiences.

[westonganger]

Regarding deletions, I'm facing an issue with the unused key concept. The gem doesn't detect them. I ran a test by including unused keys in my YAML, and they aren't marked as unused and cannot be deleted.

@JaguarRocka I just tested the missing translations functionality and it appeared to be working correctly. Can you please open a separate github issue which provides the following YAML file contents which showcases the issue.

• initial sample YAML file
• 2nd sample YAML file with some keys removed

The default filter is "All Active", you must explicitly select the "Inactive" filter option to see the inactive translations.