Why are you using fields for what sounds like should be records? Do you have a screenshot of what your system looks like?

Sure, see image here

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.

Advice: don’t do this. :winking_face:

While there are roughly spoken 6500 languages on this planet, I suspect your target list is much smaller. Care to share how many languages before we suggest some strategies?

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.

Can you rotate your data 90 degrees?

Instead of having each language be a row and each sentence be a column, make each sentence a row and each language a column.

You would have to rework you translation integration and how your app interfaces with Airtable, but it would more than double the number of sentences you could have, even on the free plan.

Thanks @kuovonne . Unfortunately, with the way the API integration between Airtable and Adalo is set up, rotating by 90 degrees isn’t possible as a solution.

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.

Sounds like I need to move over to the Adalo forum! Thank you, this has been helpful.

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.