feature-req: trace language for custom languages

[Webrow]

I've just started looking through the repo and am not a kt developer. During my use with tolgee there seems to be a feature which "big" localization packages have which is the "tracking" of a real language. If in my case I'd like to setup multiple different "English" translations, i'd like to setup a en-companyA and en-companyB which I'd like to let track another language (for example official en-en). Adding keys to en-en would add them to en-companyA and en-companyB as well (maybe with an option like auto translate). Right now languages track the base language, which would be understandable for keys, but not for translations (auto translation is not a thing right now) but this is a "future feature". I spoke to you guys in chat yday, again great software.

[JanCizmar]

So you would like to be able to select a tracking language for each language in language settings. If a string is translated in tracking language, you would like to set it also in the related language, right?

Then you would like to probably want to set base different base language for each target language as well.

So let's say you have languages:

• en
• en-companyA
• en-companyB

1. You would like to be able to set the same value to languages en-companyA and en-companyB when translation is set to en automatically.

2. And you would like to be able to set base languages like this:

• en for nl
• en-companyA for nl-companyA
• en-companyB for nl-companyB

Am I right? How would it work if I have different translations set for en-companyA and en and translation en is modified?

[Webrow]

I think the idea would be that indeed when creating a language lets say en-companyA, and have it setup to be based on en, the following things would happen: On creation of the language you setup the tracking language. In the management of the language you can turn on or off auto translation (which would be based on 1:1 match in the tracked language) After creation of the language this would mean en-companyA would be a 1:1 copy of en. When you add a key to en, it will automatically be added to en-companyA with the same translation, but the translation would be added as "unverified" (same as when you use TM now, it is "flagged" what caused it). It is mere used as means of initialization, instead of maintaining live syncs. Changing a translation in EN, would not change it in en-companyA. It only tracks its initial state and structural state. If you would want to solve a change, lets say I have [en, en-company[a..z]] and they all have the key HOME, and it is all "Home". Changing EN, would only adjust the TM. Meaning that if I would go to any of the en-companyX it would show me a suggestion of the new value thats in EN. Changing key's through all the of the tracking languages, could be done with a seperate button (triangle next to the save, "save for all tracking"). it would be a very small QOL improvement, but completely understandable.

[JanCizmar]

Can you please share links to the docs of the "big" localization packages? I would like to check their implementation.

[Webrow]

In this case I see that phrase has thrown away their support database because of their rebranding a couple of days ago. See this wayback machine, in particular the "localization a project with continuous updates" part. https://web.archive.org/web/20220125084447/https://help.phrase.com/help/how-do-i-manage-different-markets-for-my-app Sorry for the extremely small amount of documentation here, if you'd like me to write out a more complicated design doc just let me know, I am just not familiar enough with the codebase.

Op vr 7 okt. 2022 om 12:32 schreef Jan Cizmar @.***>:

Can you please share links to the docs of the "big" localization packages? I would like to check their implementation.

— Reply to this email directly, view it on GitHub https://github.com/tolgee/tolgee-platform/issues/1391#issuecomment-1271417837, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYH27MXNOV7KV243JBHE5DWB7325ANCNFSM6AAAAAAQ7MMEVU . You are receiving this because you authored the thread.Message ID: @.***>

[JanCizmar]

It would be great to have some better specification.

[cyyynthia]

I think the easy solution here is a tree structure:

Currently, the way Tolgee works can be described with a very simple tree that only has direct children of a root element:

graph TD;
  EN-->FR;
  EN-->CZ;
  EN-->NL;

The way I understand how this "tracking language" thing would work, we basically allow the tree structure to go deeper, as well as allowing data to "flow through" by default and be set to children elements (represented here by dotted lines).

graph TD;
  EN-->FR;
  EN-->CZ;
  EN-->NL;
  EN-.->ENA(EN-CompanyA);
  EN-.->ENB(EN-CompanyB);
  ENA-->FRA(FR-CompanyA);
  ENB-->FRB(FR-CompanyB);

graph TD;
  EN-->FR;
  EN-->CZ;
  EN-->NL;
  EN-.->ENF(EN-Formal);
  FR-.->FRF(FR-Formal);
  CZ-.->CZF(CZ-Formal);
  NL-.->NLF(NL-Formal);

By thinking about this problem like a tree-structure, I think we can somewhat easily pull off this tracking thing; provided I understood the problem right :p

[Webrow]

[Edit was a premature enter] @cyyynthia I think we are almost there. Sorry for the wait but was discussing it at home over the weekend. It is a "double" problem. I think the Default language should be used for tracking keys. A tracking language is the base for a certain language, A locale tracking a local language would be for "lingo" I don't know what the correct term is in translatorland. Ill try it with a Graph.

graph TD;
  NL-.->NL-CompanyA
  NL-.->NL-CompanyB
  NL-.->NL-CompanyC
  EN-.->EN-CompanyA
  EN-.->EN-CompanyB
  EN-.->EN-CompanyC
  EN-->NL
  EN-->CZ
  CZ-.->CZ-CompanyA
  CZ-.->CZ-CompanyB
  CZ-.->CZ-CompanyC
  EN-->FR

In this case all EN-Company ones are just "locales/lingo" of a selected English, so any company can have their own slang. With all these relations we can throw in some smart things like, automatic key addition, knowing what language is needed for machine translation or TM. Adding a K,V to NL can make sense to set the K,V, to all of its children as well, or at least take NL[key] as a suggestion for TM when filling in NL-Company[key], instead of it suggesting EN[key]. (since EN is now considered as a base language). Base languages could serve for automatic key creation on other languages for example, but not for TM or machine translation suggestions (that role is for the tracked language).

Is it somewhat clearer, or did I just make it more confusing?

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.