Skip to main content
Solved

Going beyond 500 columns for translations

  • August 11, 2020
  • 9 replies
  • 53 views
B

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!

Best answer by Barrett_Nash

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.

9 replies

ScottWorld
Forum|alt.badge.img+35
  • ScottWorld
  • Genius
  • August 11, 2020

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

B
  • Barrett_Nash
  • Author
  • New Participant
  • August 11, 2020

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.

B
Forum|alt.badge.img+19
  • Bill_French
  • Inspiring
  • August 11, 2020

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?

B
  • Barrett_Nash
  • Author
  • New Participant
  • August 13, 2020

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.

kuovonne
Forum|alt.badge.img+29
  • kuovonne
  • Brainy
  • August 13, 2020

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.

B
  • Barrett_Nash
  • Author
  • New Participant
  • August 13, 2020

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.

B
Forum|alt.badge.img+19
  • Bill_French
  • Inspiring
  • August 13, 2020

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.

B
  • Barrett_Nash
  • Author
  • New Participant
  • Answer
  • August 13, 2020

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.

B
Forum|alt.badge.img+19
  • Bill_French
  • Inspiring
  • August 13, 2020

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.

Terms & ConditionsAccessibility statement