search

WeblateOrg / weblate

Web based localization tool with tight version control integration.
https://weblate.org/
GNU General Public License v3.0
4.54k stars 1k forks source link

Document when use component as a glossary #8131

Open absoftware opened 2 years ago

absoftware commented 2 years ago

Describe the issue

Steps:

  1. Add component "iOS" (there is 6 files for 6 languages)
  2. Add component "iOS Special Brand" (there is only 2 files for 2 languages)

Expected: Weblate creates component for "iOS Special Brand" with 2 languages. We do not want commits in "push branch" with new files for languages.

Current: Weblate adds files for 4 "missing" languages only because they are used in another component.

Info:

I already tried

Steps to reproduce the behavior

  1. Add component "iOS" (there is 6 files for 6 languages)
  2. Add component "iOS Special Brand" (there is only 2 files for 2 languages)

Expected behavior

Weblate creates component for "iOS Special Brand" with 2 languages. We do not want commits in "push branch" with new files for languages.

Screenshots

No response

Exception traceback

No response

How do you run Weblate?

Other

Weblate versions

Weblate 4.14 self-hosted

Weblate deploy checks

No response

Additional context

No response

nijel commented 2 years ago

Is any of these configured as a glossary?

github-actions[bot] commented 2 years ago

This issue looks more like a support question than an issue. We strive to answer these reasonably fast, but purchasing the support subscription is not only more responsible and faster for your business but also makes Weblate stronger.

In case your question is already answered, making a donation is the right way to say thank you!

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because there wasn’t any recent activity.

It will be closed soon if no further action occurs.

Thank you for your contributions!

absoftware commented 2 years ago

@nijel Thank you for your response. Yes, I use them as glossaries, but first of all they are just regular components. I will make additional tests and will come back to you. I will compare behaviour when they are glossary vs no glossary, shared repo vs not shared repo. But if it's not a bug, then what is the difference in comparison to plugins to keep all components with the same set of languages? If it works like that then this plugin makes no difference.

absoftware commented 2 years ago

I've made tests.

Steps:

  1. Add component "iOS" (there is 6 files for 6 languages) - NO GLOSSARY/GLOSSARY don't matter here
  2. Add component "iOS Special Brand" (there is only 2 files for 2 languages)

Result:

So yes, we could assume that glossaries needs to be "all-language" components. However I can remove languages from glossaries as well and they are not "all-language" components. I don't understand why we need all-languages for glossaries by default. If component is associated to repo, then it creates new files for new languages without any wishes from anyone. It matters for me, because we have many components, and creating them later like that forces us every time to remove added extra files manually.

More over what is the difference between "glossary" vs "add missing files" add-on in that case?

Besides... What is the reason to have so many ways of suggesting translations? Glossary vs suggestions vs automatic suggestions (from ad-ons).

In general it sounds for me that we could remove term "glossary" from Weblate totally and treat all components as possible source of suggestions. It's good to have good overview what is going on in the project when making new translations. Why someone would like to not use that? ...just tried to explain why I use all components as glossaries.

We are making prototyping which translation tool should we use.

PS. Shared repo and the fact if first component in use case is glossary don't matter. Only matters if second component is created as glossary.

nijel commented 2 years ago

See https://docs.weblate.org/en/latest/user/glossary.html for information how glossaries are used.

github-actions[bot] commented 1 year ago

This issue has been automatically marked as stale because there wasn’t any recent activity.

It will be closed soon if no further action occurs.

Thank you for your contributions!

absoftware commented 1 year ago

@nijel Thank you for the link. I read a lot documentation before using it, however it doesn't explain why Glossary needs to be all-project-languages complete. It would be nice to make it more flexible, that's why I reported this issue 🙂 Re-configuration of components (re-creating them is annoying as it creates unwanted new files in the repo all the time).

nijel commented 1 year ago

The glossary needs to have all languages to make glossary handling easier in the rest of the code - for example, it does not have to check whether a glossary exists before adding terms to it.

absoftware commented 1 year ago

I actually converted my 21 modules from Gloassary to normal component. This operation (only unchecking of "Use as Glossary") created files in repository as well. And we definitely don't need them. So those files are created when we create new Glossary Component, and when we convert Glossary into normal component as well. Now I need to go through them all and delete not wanted files. It produces 42 unwanted commits and a bit of manual work.

nijel commented 1 year ago

Why did you configure all the components as glossary in the beginning? Is there something confusing in the setup process?

absoftware commented 1 year ago

It was giving good suggestions for translators based on another components. By the way it a bit confusing, because suggestions, automatic suggestions and glossaries give suggestions in a bit different way. Glossaries was the most easy in use as they are visible in right panel. All others you need to switch tab at the bottom. More over documentation says that regular components can be used as Glossaries from time of some release. So I tried. I know it's mostly predicted to some project-specific terminology, but tried to use it as additional way of giving full overview across of all components.

nijel commented 1 year ago

Okay, we really should document when using component as glossary is a good idea and what are consequences of that.

nijel commented 1 year ago

Maybe @orangesunny or @comradekingu might take a look at this?