| This looks super cool. I got a bunch of questions! 1. Am I correct in understanding this is meant as a client-side only solution for now? Right now we have a pretty complicated translations process that needs to support translations that are spread across the client and server. Would this support a hybrid approach like that? 2. Another question I have is where does the `translations.json` file come from and where is that stored? Is that just generated by the CLI and then we have to deal with serving that however we want? 3. Is there one `translations.json` file per language? One with all of them? Are there performance concerns with sending large files like that over to the client? This is a general question for me to other developers of large sites: how do you deal with tons of translations? 4. Any plans to support existing translations? E.g. if I have an existing set of translations keys and values can I plug those in somewhere? I know y'all are bootstrapping so it wouldn't surprise me if that's a Future feature. Again, love the idea of this, and it would be super cool if this solves the problems due to complexity we currently have with supporting a ton of languages. -- For some background our current solution involves a generating a rather large (> 1MB) `translations.json` file for each language that we serve to the client via a CDN. Typical map of keys to values. We create the keys ourselves as we go along something like `dashboard.salesCard-helpText`. Then we have to kludgy Drupal instance to populate the key and value, add some tagging to show it needs to be translated. Translations get entered into that Drupal instance. All of this is entered manually. Then that gets used to generate the `translations.json` file I mentioned earlier. We have plans in the future to overhaul the process. |
2. The 'translations.json' file is autogenerated by the CLI and updated each time you pull translations. It's automatically bundled in the deploy process so you don't need to do any extra work.
3. Currently we have a single translations.json file. Space hasn't been an issue yet but we plan to add splitting to reduce it. For dynamic content which can be large, we have solutions where we can serve the content as a CDN. We could also give clients a microservice if they would like to self-host or directly update a cache on disk on the deployed machines. Still experimenting with the best/easiest way to do this.
4. Sure thing, we have a file upload in our dashboard right now, but we want to add this to our CLI to make it more accessible.
I understand your frustration and one of our core philosophies is to do away with keys completely. Our keys are auto-generated and not touched by the user. The code can have the actual text which is a lot more readable. Ping me at abhi@langapi.co and I'd love to help solve your problems.