Bubble Translation Ideas

[eren]

Hello; I have some ideas as a Bubbler with clients in different languages, and some of my other friends’ ideas. I hope you will be interested and put forward the better ones.

Hopefully, the team will be interested in @allenyang

The editor is difficult to use and contains many steps to change, below you can see the effort I have spent to translate a sentence.

1- Apptext editor - Apptext editor change that would be very helpfull

2- Suggested by @fayewatson : Page-level checkbox - Change all static text to Apptexts

I would find it easier if there was a ‘page setting checkbox’ for app texts, instead of needing to define them one-by-one. For example, if there was an option such as “Define app text for all static text elements on this page”, the editor would automatically create App Texts for each of the static text elements on a page (not dynamic data). All of the App Text Labels for the app text could automatically be the static text which was typed into the text element itself. I think this would save a ton of time because you would skip the step of clicking App Text and defining the name of the App Text on the page for every text element.

3- Suggested by @fayewatson : Apptext Label

If the entire application is to be translated, I also think it would be easier for the text elements not to display"[App Text] [Label of App Text]", but instead to just say the “[Label of App Text]” and have the “App Text Editor” become visible when editing the text element itself (as you have in your screenshot on the original post). This would make scanning and reading the page in the editor much easier (in my opinion), since not every word would begin as “App Text”.

4- Convert Apptext to…

If the above ideas are well suited, maybe we can give Apptext another value. Date, number, etc. This will be easier than using hidden inputs. For example, if Apptext returns a number and not a ‘text’ value, we can perform mathematical calculations on those text elements. Hidden inputs and so on will, therefore, be redundant.

5- It may also improve the use of “When an unhandled error occurs” messages.

6- Apptext and JSON may be well suited in this situation too. Apptext is selected dynamically, so JSON can easily serve many purposes within the Apptext. Having the ability to load JSON elements into Apptext would allow some flexibility for different situations.
For example, setting a repeating group’s content type to ‘text’ and using the Apptext in JSON format as the primary data source to provide the list of items. Then within each cell would be the ‘current cells App text product name’.

I hope I can explain it properly.
Let’s paste a Json into an Apptext?.
If the Apptext? type is JSON, the Dynamic editor will allow us to easily select the Json fields in the text.

Like
Parent group’s product name
Apptext?'s product name

Thank you very much for your interest @fayewatson @luke2

[allenyang]

Thanks for pulling these ideas together @eren!

[Arche]

I’m curious if there is any progress with these suggestions…
Just submitting my +1 here - any changes that make apptexts more convenient to use would be highly appreciated
Also - how do apptexts and option sets relate? Im’ trying to understand if I can make option sets multilingual or do I have to use different option sets for different languages?

[allenyang]

Hi Arche,

Currently option sets and app texts are completely separate.

[Arche]

Hi allenyang,

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

[allenyang]

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

[devin.fraze]

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.

[eren]

I can’t edit the original post

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.

@allenyang

We may try squeezing it into a future hackathon but it could be a bit big…

We look forward to it!

Thanks!

[kreilisjanis]

Hi!

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!

[allenyang]

Hey all,

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

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

[devin.fraze]

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.

[kreilisjanis]

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.

[kreilisjanis]

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

[allenyang]

We try to be honest with any ‘bad’ news

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

[devin.fraze]

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

[ts11]

@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. myapp.com/en/account) 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.

Thoughts?

[sudsy]

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?

[ts11]

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.

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

[ts11]

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