I am using Airtable as the database backend for translations to an app I have built. Basically, ever column is a string for text that I then link to in the app.
While 500 columns is generous, it is limiting my freedom to design the app since there are more than 500 strings that need to be indexed in the app.
My ideal solution would be for there to be a paid solution that would allow me to go beyond 500 columns, but that doesn’t seem to exist.
Otherwise, my ideas are:
Use the 500 lines more efficiently. I have been doing this but am running out of low hanging fruit, 500 strings is not such a high limitation when you consider the amount of text in an app
Link Airtable databases together, where the user would select a Translation database 1 for the first 500 strings then a Translation database 2 for the next 500 strings, but this is a bit ugly for the users. I haven’t figured out a way to auto populate the second database of the selection of the first database, I feel like there has to be a way but I haven’t figured it out yet
I’m integrating using AirTable as an API to another service called Adalo. The system is working well in the app (you can see a live version at app.infiniteup.africa) but I’m happy to be told there is a better way.
Very fair @Bill.French ! If you have any recommendation, I’ll gladly listen. I’ve kind of just cobbled something together. I’m using a no code platform called Adalo integrated with Airtable so I am limited my own technology capacity.
I’m making a business management software suite for small African retailers and being very local with languages is a key aspect of respecting the end user. We’re targeting about a dozen languages which are most widely spoken across Africa.
Better stated, by using the no-code integration that Adalo prescribes, you are forced to make data schema design choices which themselves have poor outcomes.
To make this work well (as @kuovonne suggested), translated variants should be columns and sentences to translate must be rows. This is the only reasonable way to create a normalized and performant data model for this information.
How Adalo is set up, is also not likely ideal. Adalo, for example, did not force you to create a data schema with 500+ columns and just 12 rows of data. Nor would it necessarily reject a more reasonable approach where sentences to translate are records and language variants are columns. I’m certain Adalo is capable of dealing with a 500 record table with 12 language columns.
I think that’s a good step. Before you do, be prepared to describe the data in a more reasonable format with sentences in rows and translations in columns.
Without seeing the rendering requirements on the Adalo side, it is difficult to advise you on that integration strategy, however, I’m certain Adalo can access the data in any format - even the one recommended by @kuovonne.