lang

[gerardwebb]

see https://github.com/amplify-edge/shared/tree/master/tool/bs-lang-srv

dev-md has the design staggered for now

[gerardwebb]

I realised that its ok for use to use the file system ( and hence git ) as the translation cache.

For example this:
https://github.com/amplify-edge/mod/blob/master/mod-disco/service/flu/i18n/lang_en.json

SO bs-lang just needs to check the lang_en.json, and on cache miss call google translate.

[alexadhy]

ok, tonight i'll start

not going to bother doing local cache with genji btw

just download the sheets

• if the translation doesn’t exist in local cache (csv or json) does the call to google sheet
• if the translation doesn’t exist in google sheet do call to google translate api
• as for client server architecture i’m not going to do it now nor probably in the near future, if i do it will probably after the whole medical things features are complete. Why?

1. Because our infrastructure isn’t even close to ready. I.E. QoS, can we even make it quick enough? etc etc that’s a monstrous effort.
2. Because text transformation (like spewing translated error msgs or translate protobuf message) can be done via transformationFunction that can be a placeholder right now.
3. Current Authentication and Authorization layers aren’t in anyway useful or sufficiently covered service-service communication. I suggest using very much mature solution like Auth0, DexIDP, OPA, Keratin, etc instead of rolling our own for this, totally not worth it IMO and totally not sure if it's even secure.
4. Non technical: I'm afraid this will be another monstrosity. Booty and maintemplatev2 already have overarching and lofty goals and i want to make sure that one thing is built right or not at all.

for instance:

Booty's responsibility includes:

• Dependency and Package Manager
• Bootstrapper
• Service manager
• Self updating agent
• Configuration manager for not just internal stuff but also 3rd party
• Responsible for builds
• Makefiles manager
• Wrapper for git and setups etc
• Development Environment setup
• Release and probably also changelog manager

All of them terraform and ansible already covered and doing it much better. TiUp can do it because they have the resources to do it.

Lang is pretty much going to cover almost as large of an area booty covered.

[gerardwebb]

comments inline.

ok, tonight i'll start

not going to bother doing local cache with genji btw

just download the sheets

• if the translation doesn’t exist in local cache (csv or json) does the call to google sheet

Thats not what i meant in: #13 (comment)
My intent is that file system ( git ) IS the durable cache. No google sheets at all.
I changed it because its much less work. The intent of the functional needs in the markdown doc is to roadmap what we will need eventually, and then work backwards to what we can do now that is the right thing to do now and reduce as much refactoring going forward towards what we eventually need it to do.

• if the translation doesn’t exist in google sheet do call to google translate api

yes, but instead "if the translation does not existing in the file system, do the call to google translate api"

• as for client server architecture i’m not going to do it now nor probably in the near future, if i do it will probably after the whole medical things features are complete. Why?

I dont want you too either..
Me and Leyla are doing due diligence on the requirements for verticals in order to NOT write code we dont need.
But am glad you engaging. But better you raise all these things in Telegram / gmeet.

I feel that our might have gotten confused about roadmap and versioning of it. Can explain over gmeet...

1. Because our infrastructure isn’t even close to ready. I.E. QoS, can we even make it quick enough? etc etc that’s a monstrous effort.

yes your right. thats why the roadmap it such what it is.

2. Because text transformation (like spewing translated error msgs or translate protobuf message) can be done via transformationFunction that can be a placeholder right now.

yep makes sense...agree

3. Current Authentication and Authorization layers aren’t in anyway useful or sufficiently covered service-service communication. I suggest using very much mature solution like Auth0, DexIDP, OPA, Keratin, etc instead of rolling our own for this, totally not worth it IMO and totally not sure if it's even secure.

I see your point and 100% agree.

We need to do further analysis on what we need and how best to do that, hence why i am doing that due diligence.
If you want to get more involved in it it might make more sense.

I wont go into it here though as too much to explain. The Docs have alot of info about it that maybe needs to be further refined with you. And then things that we knwo we dont knwo and things we dont knwo that we dont know. In other works, spec out use cases and then spec out technology that fits those use cases.

Fro my analysis we need a Identity system that has some flexibility in that it is pluggable actually. From the docs its quite clear i feel. SO then logically, we look at biz roadmap, and then look at tech roadmap alignment and then "mature solution" fit.

So lets talk about this in a meeting...

4. Non technical: I'm afraid this will be another monstrosity. Booty and maintemplatev2 already have overarching and lofty goals and i want to make sure that one thing is built right or not at all.

for instance:

Booty's responsibility includes:

• Dependency and Package Manager
• Bootstrapper
• Service manager
• Self updating agent
• Configuration manager for not just internal stuff but also 3rd party
• Responsible for builds
• Makefiles manager
• Wrapper for git and setups etc
• Development Environment setup
• Release and probably also changelog manager

All of them terraform and ansible already covered and doing it much better. TiUp can do it because they have the resources to do it.

Lang is pretty much going to cover almost as large of an area booty covered.

And so then ??