Going beyond 500 columns for translations

Topic Labels: Base design
Jump to Solution
3159 9
Showing results for 
Search instead for 
Did you mean: 
5 - Automation Enthusiast
5 - Automation Enthusiast

Hi all,

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

Anybody have any advice? Would be appreciated!

1 Solution

Accepted Solutions
5 - Automation Enthusiast
5 - Automation Enthusiast

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

See Solution in Thread

9 Replies 9

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 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.

5 - Automation Enthusiast
5 - Automation Enthusiast

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.