Forum Academy Marketplace Showcase Pricing Features

Bubble Translation Ideas

Hi allenyang,

Thanks for clarifying!
And as for the other question - any news on the translation side?

No timeline on the other feature request unfortunately. We may try squeezing it into a future hackathon but it could be a bit big…


A bump/+1 from me as well. Either this or just some other way to mass edit translated texts.
Still, I’m very grateful for what bubble currently has.

I can’t edit the original post :frowning:

7- On the Languages tab, there should be an option to add a new AppText.

This makes things easier, especially for some words. Instead of returning to the design, creating a text and coming back to the tab and typing your translations, it would be nice to add them in this tab.

8 - A filter for "Show Empty Inputs

I must say I urgently need this. If the application contains too many sentences, it is very difficult to detect some deficiencies. It is necessary to scroll very carefully to add a translation of a word.

As you know, when you create an Apptext, we create an ID for your Apptext, not a word or phrase. This leaves the input of the original language blank.

First you must write the original language. In this case, the original language automatically fills in the entries of other languages, even without translation. This makes it more difficult to detect missing translations.

9- A Rich text editor where we can edit each language individually

Editing apptext is difficult. It would be nice to have a Rich Text Editor that can be controlled separately for each language by adding a button here.

Bu işlem geri alınamaz
This action cannot be undone

In situations similar to the above, there is serious time loss, even in just two languages. I can’t imagine those with much more translations.

Bu işlem geri alınamaz
This action cannot be undone

For the places where I want to write bold here, either I have to go back to the editor, create the translation, make the markups and go back to the language tab and paste or I have to manually add the relevant tags. And if we want to change color? Things get even more complicated in an underlined, strikethrough or similar situation.

10- A floating group to facilitate switching between languages
As you can see in the above .gif, it is difficult to navigate between the two languages. It would be great if this area was a floating group.

We look forward to it!




Just wanted to follow up on this topic. I’ve been exploring Bubble for the past two weeks and started building the new version of our job board for which I already had designs prepared. I’m very impressed with Bubble and how intuitive the workflow logic is once you understand it.

However, it’s painful to see that I might not be able to build my app in Bubble since I need it to work in several languages. Sure, the apptext UI is cumbersome and @eren’s ideas would make translation management much easier but at least apptexts work since they’re so simple.

However, implementing multiple-language dropdowns and other non-text elements is trickier since you need to build new tables for these options (and I suspect they’ll slow the app down somewhat since we can’t use option sets) + sorting seems to be an issue. And I still haven’t found any way to have the native multiselect dropdown in several languages, since the conditionality of a language dropdown element does not allow to modify the option caption (which surprisingly is the case in the simple dropdown).

I’d absolutely love to buy into Bubble’s idea of scaling up as the app grows - I’d love to be able to develop our entire platform without a full-stack developer, and so far, I haven’t seen any other significant limitations. However, it just seems that building multilingual apps was not something Bubble’s team ever considered when planning the product so almost everything related to several languages on the app feels like a workaround.

@allenyang - what’s your philosophy towards making multi-language support one of Bubble’s priorities? Do you have any advice on the best approach to plan/build the architecture for a multilingual app?

Many thanks!

Hey all,

Thanks for sharing all these ideas! They’re great; I’m bookmarking this thread for future reference :slight_smile:

@kreilisjanis to your question - we certainly view multi-language support as a key feature of the platform. We certainly see it in the metrics how international our userbase is. To your point, we think the existing features in this area are a pretty good starting point for creators to internationalize their apps. There’s always more we can do (both making the current features more usable, e.g. a lot of the ideas in this thread, and building new features in this area), but this is not high up on our roadmap currently. The big roadmap items that will occupy most of our engineering resources for the near future are spent on platform-wide initiatives which will benefit all apps (e.g. performance, reliability, the editor redesign, the responsive editor revamp). Doesn’t mean we won’t squeeze in a small improvement here or there, but no major features relating to translation / internationalization planned for now.


Actually I’ve found a workaround for your issue that I haven’t seen anywhere else on the forum.

You can paste dynamic expressions into the “option caption” part of dropdown instead of using the “current option” expression. (This also works other places that you can’t usually edit through clicking on it and using the standard “insert dynamic expression” flow.)

For example, you could create a dynamic expression"do a search for [caption display]{where display_language = current language; and display=‘current options value’}". And then copy that and paste it into the option caption field of the dropdown (although you’ll have to set the “current option value” part of the search after you paste the dynamic expression in.)

This will allow you dynamically insert language specific option text in any dropdown.

1 Like

Many thanks, @devin.fraze! I’ll definitely try it out! This solution is something I had not seen anywhere on the forums (and I did a thorough search through everything language-related).

How much do you think this will affect performance, though? From what I’m reading, any “do a search for” call will slow the page load down somewhat.

@allenyang - I appreciate the honesty and the openness. There’s somehow this vibe of a friendly community around Bubble that, for me at least, sets it apart from other solutions.

Given that translation support won’t be a big roadmap item for the near future, it seems it might more sense to use some external translation tools on top of Bubble (like Bablic, Weglot, Conveythis etc.). Do you have any advice/suggestions which tools might integrate best with Bubble? I’d appreciate it a lot.

We try to be honest with any ‘bad’ news :slight_smile:

This isn’t an area I’ve personally explored but maybe somebody else who catches this thread has!

1 Like

Speed is a great question. While I took the time to figure out if such things were possible, I have not done any testing on load time. I personally am trying to use design and icons to reduce the amount of written words used.

The other crucial question seems to be if the site indexes the other languages as well. But best I can tell, if things are tied to the user’s language, then it should index properly

1 Like

@kreilisjanis and @devin.fraze, I’ve spent a fair bit of time recently puzzling through multi-language app development in Bubble, and I think I’ve arrived at a somewhat novel strategy that might be of interest to those on this thread.

Before diving into specifics, though, let me give some more context on our build and our objectives:

  • Our application will be content-heavy, and most of this will be dynamic, user-generated content.
  • We have elected to build a Single-Page Application that relies heavily on URL routing (via @sudsy’s Sudsy plugin) and conditional logic to render our content and UI.
  • Obviously, our main concerns in developing a multilingual strategy were performance, cost and scalability

With all of this in mind, here’s where we’re heading. I should stress that this is still mostly conceptual, as we’re in the early stages of actually building the damn thing. As such, critical feedback is welcome.

  1. We have created a separate data type called “language” to track supported languages
  2. We have created a reference field on each user to track their native language
  3. This selection can be toggled from the header, as well as in account settings
  4. Our SPA has a language tag as the base URL (i.e. and we’ve set up automatic redirects to direct users to the appropriate path
  5. All navigation elements are set relative to this base URL path
  6. SEO/Social Tags/HREFlang tags are set dynamically as a function of this base URL path
  7. All text elements are rendered dynamically as a function of this URL path

The last point warrants some more explanation. We have created our own custom data type for text elements, which we substitute anywhere we would normally use a native Bubble text field.

For instance, we have a data type for profile. On this type, we have a field for “biography.” Rather than make this a standard text field, we refer instead to our own custom “text” thing. This thing, in turn, holds a list of “translations,” which is another custom data type. Each “translation” contains a text string, a language identifier (a reference field to our custom “language” data type) and a yes/no field that tells us whether this is the original content or a translation of it.

Now, if we wish to display the biography associated with this profile on the front-end as a text element, our data source would be the list of this profile’s biography’s text’s translations:filtered by the current language, as defined in the URL structure.

From a content management perspective, whenever we have a data creation workflow that involves text elements, we will schedule an API workflow that iterates through those elements, translates them via Google Translate API and saves them as “translations” to the appropriate “text” entry in our DB, where they can be referenced in the future without incurring additional cost or getting bogged down with numerous API calls.

This scheme has the added benefit of making it stupid easy to add support for additional languages in the future. Anytime we wish to do so, we can simply create a new “language” entry and have an associated API workflow that will recursively iterate through our “text” elements, identify the original text and translate it into the target language.



I’ve done just a cursory reading, but wow, it seems really well thought out. However, I’m a bit fuzzy on the language URL parameter. Since the URL router doesn’t work on the home/index page, the URL structure suggests there’s a separate Bubble page for each language. Is that right?


Thanks, @sudsy! I’m hoping it’s well thought out. I’ll definitely update this thread once the build is complete. Regarding your question: We’ve set up a separate, custom data type for language. That said, we would be redirecting from the index page to the base page of our SPA, which would be of type “language,” with the URL prettified so that the language abbreviation would be the base path. Do you foresee any obstacles to that setup working as envisioned? Again, still working out the kinks with this and getting acquainted with Sudsy.

Nothing jumps out at me as unworkable, but I’ve never done anything quite like that myself, so I’m eager to learn from your experience. I appreciate you sharing your design philosophy and will be reading your follow-up posts.

1 Like

Thank you, sir! Our app should be live in the next month or so. Fingers crossed :crossed_fingers:

1 Like

@ts11 - looks impressive. From my first reading it sounds promising. If it works, you should do a manual for the rest of us. :slight_smile: Fingers crossed everything works as planned!

1 Like

Haha. If it works, I would be honored to do so. I’ll keep you posted :beers:

1 Like

Brilliant. We’re looking to add French support (we’re in Canada and 20% of Canadians are native French speaking). Thanks for thinking of this!

1 Like

Certainly! Let me know how it works out for you.