Comment by j on "How do you deal with translations in frequent releases?"

I only know 3 classic approaches to translations regardless of scale also we only have 3 possible modi operandi

pre defined
immanent processing
post processing
pre has the problem of flexibility and missing cases
immanence has the problem of doing things more than once
post has the delay plus the possibility that other changes already interfere

So those are the classic trades we can mix them to some degree as you know but in my experience those are the obvious problems of each application. And you need to find a process that works good for your team.

About the solutions:

Catalog system (gettext and such) done afterwards
Map system (key value store)
Service system medium.com/airbnb-engineering/launching-airbnb-jp…

Personally I worked with the first two technologies and with all 3 operational modi.

If you ask me what is best .... I don't know the only thing I am pretty sure is that you should start with a base language where you easily get translators so you only use 1 level of semantics between languages.

These are my only thoughts atm.

The frequency is not the issue, the coverage can be on the other hand if you give your translators and services the right tools this can be easy and efficient.

The problem with any system is state to time where you would need to track the current version + translations catalog just to be sure.

Also the next questions are mixed stacks who make this problem even more interesting.

about VCS maybe don't make a release tag :) just do the checkout and rsync the files to a package folder? without vcs? I know it's hacky .... just thinking out loud

Yeah I guess it's either pre, during or post. Pre is ready faster, post is fewer mistakes...

I didn't get the part about "The problem with any system is state to time" :-/

Last paragraph sounds like making a branch would be easier :-)

Mark ah yes a branch is even better although I on purpose wanted to remove the whole version system to really get a fixed state at a certain time. But yes a branch can get the same result :) maybe cleaner and better to comprehend :D

The problem with any system is state to time

Maybe this makes more sense:

You have two different states and you cannot define a specific tag where you know the translation and the source do match up. to fix the state to a specific time.
If you don't have all translations at once and you do 2 - 3 different releases and one rollback and all of the sudden :) so the state the application should be in does not match with the translation state.

I think a better way to express it is: state inconsistencies. However those are achieved :)

Yeah those state inconsistencies are a tricky part. I am not quite sure how important it is to keep exactly in sync, or if translations just need to be as new as code. Since 90+% of translations changes are additions, not much breaks if they're too new...

Mark true :) but as soon as you go parallel problems of consistency will always arise. And as soon as you can go into two directions on the progress axis you even get problems with sequencial consistency.

Anyhow this all just speculations :) if you find a good solution please let me know. I bump into the problem every 2-3 years and I usually kill it with defined processes where the initial release is just english and the rest gets filled in :)

Search Hashnode