I wanted to share a backend/frontend architecture we built for Biznet Solutions. We are building a vertical OS for local businesses in the Balkans, which presents a specific data problem:
Multi-Lingual: We support 9 languages (English, Serbian, German, Turkish, etc.).
Dual Alphabets: We handle both Cyrillic and Latin inputs.
Shareability: Search results need to be shareable via a direct link.
The Solution: “Word Soup” Indexing + URL Parameters + Normalization
Part 1: The Backend (The “Word Soup”)
Instead of translating on the fly (slow + expensive), we translate on creation.
Trigger: When a Business creates a listing.
Workflow: We send the Title + Category Tags + Custom Keywords to Google Translate (Backend Workflow).
Normalization (Crucial Step): We take the huge string of 9 languages and apply :lowercase to the entire text block before saving.
Storage: We dump this normalized “soup” into a single text field called search_index.
Part 2: The Frontend (URL-Driven Search)
We don’t filter the Repeating Group based on the Input box directly. We use the URL as the “Source of Truth.”
Workflow: When ‘Input Search’ value changes $\to$ Go to page (Current Page) $\to$ Send parameter q = Input's value.
Repeating Group Data Source:Do a search for Listings $\to$ Constraint: search_indexcontainsGet q from page URL :lowercase.
Why we did it this way:
Partial & Case-Insensitive Matching: Because both the Index and the URL Query are forced to lowercase, a user can type “sched” and it will match “Scheduling”, “SCHEDULING”, or “scheduler” instantly.
Zero Latency: No API calls during search. It’s just a native DB filter.
Deep Linking: Users can copy/paste the URL to share specific search results.
Polyglot: A user types “Sastanak” (Serbian) $\to$ The URL stores ?q=sastanak $\to$ The RG finds the English listing “1-on-1 Meeting” because the Serbian keyword is hidden in the search_index.
Sounds like you came up with a good system that works for you, congrats!
Also speaking of translating and all that…
I clicked on a link in Bubble earlier today to view a site.
The site had a huge hero image with text on it. It also had several other images with text on them.
The hero image and all looked good.
Since the site was in another language, I clicked to translate.
Well, none of the text on the images was translated because the text was baked into the image. This is one thing that really screams unprofessional. It’s not that hard, and it’s also more advantageous to use actual text elements over images…
the text can be searched, read by a reader, and, not to mention, read by someone who doesn’t speak that language.
Anyway, that’s my unhinged rant for today, but I see that a lot, and as I said, it just screams unprofessional design.
100% agreed. Text-in-images is a nightmare for accessibility and SEO.
That is actually why we went the extra mile for the UI itself, too. We don’t rely on the browser’s ‘Google Translate’ overlay. We used Bubble’s native App Text parameters for the entire interface.
It was a massive undertaking (spent countless hours manually tuning strings), but it allows us to:
Control the Design: We ensure button text actually fits, regardless of language length.
Cultural Context: We can use the culturally correct phrase rather than a literal robot translation.
Speed: The app loads natively in the user’s preferred language instantly—no ‘flash of untranslated text.’
It’s a lot of work upfront, but for a platform serving 9 languages, the trust it builds is worth it.
I think the key there is the use of ‘alt-text’ as if the text is part of the image, I do not believe a screen reader is reading that unless the alt-text has it. alt-text in bubble on images can be set dynamically, so it is easy to have it in multiple languages. I might be mistaken though.
alt text and captions underneath help simplify that
This means you can not use the go to page action to change a language while on the same page, unless you do a page refresh, unless bubble fixed that issue.
Is this preference based on the browser or a saved value in your bubble database?
It’s actually a hybrid approach depending on the device:
On Mobile (Android Wrapper): We pull the language directly from the device’s OS settings. If a user’s phone is set to Serbian, the app detects that and serves the UI in Serbian automatically on first load.
On Web (Browser): We default to English for anonymous visitors. Once a user signs up or logs in, the app switches to the value saved in their User's Preferred Language database field.
We considered using IP-based geolocation to guess the language for web visitors, but we decided to keep it simple (English default) for MVP to avoid issues with VPNs or tourists. That’s likely a Phase 2 update.
When a user selects their language and hits Save, our workflow updates the database field and then immediately triggers a Page Refresh.
To the user, it just looks like a quick flicker or a fast reload, but under the hood, we are forcing the app to re-fetch the correct language strings. Sometimes you have to think like a magician—hide the technical constraint behind a snappy interaction
You can get magician like quick change with no flicker or page reload without using app text or url parameters and instead use url path lists (better for SEO)
By not using app text and url parameters, you can get faster language changes on web when switching from default english to user preference…you can also get more SEO benefits from URL path lists instead of the URL parameters.
That is a really interesting approach with the URL paths. I can definitely see the speed/SEO benefits there.
For our specific use case, we ended up sticking with Native App Text mostly due to the Mobile Wrapper constraints.
Since we are wrapping this for the Play Store (Android/iOS), we rely heavily on the wrapper’s ability to pull the OS language settings. Since wrappers often mask the URL or handle navigation differently than a standard browser, have you found the URL Path method (/sr/dashboard) to be reliable inside a WebView wrapper?
We also have about 300+ translation strings with dynamic inserts (using [] placeholders), so we are doing a bit of ‘Find & Replace’ heavy lifting either way.
Would love to hear how the URL path setup handles the native mobile context!
That is a really interesting approach with the URL paths/Option Sets. I can definitely see the speed (no reload) and SEO benefits there, especially for a pure web app.
For our specific use case, we ended up sticking with Native App Text for two main reasons:
Scale & Maintenance: We are currently supporting 9 languages (with more coming soon). Managing 300+ text strings across 9 languages (2,700+ entries) felt more manageable in the Native App Text tab than building/maintaining a massive Option Set structure. How do you find the maintenance workflow for Option Sets when the language count gets high?
Mobile Wrapper Constraints: Since we are wrapping this for the Play Store (Android/iOS), we rely heavily on the wrapper’s ability to pull the OS language settings. Since wrappers often mask the URL or handle navigation differently than a browser, have you found the URL Path method (/sr/dashboard) to be reliable inside a WebView wrapper without breaking the ‘native’ feel?
We also have dynamic inserts (using [] placeholders) in many strings, so we are doing a bit of ‘Find & Replace’ heavy lifting either way.
Would love to hear how the URL path setup handles the native mobile context! The zero-refresh speed is definitely tempting for V2.
The linked post and original concept was from 2023. Now, I use API Objects, instead of the plain Option Set. I create a JSON file for each language, use an option set of Languages with an attribute for the file. Then I use that file to be read as API Objects to populate the dynamic text in the same way the APP Text allows for.
The main reason for this instead of App Text is not the flash for the page to be refreshed, but the data load that occurs for most SPAs when the page is fully refreshed. If the flash and data load are not an issue, than app text is good.
From my understanding communicating with developers who provide wrapping services, the URL is not seen but it is interpreted and understood and how the app actually does navigate through different ‘views’, so it is not as if the URL path is lost or inaccessible because the app is wrapped.
In the same way that you are using URL parameters and the database for user language setting, you can use the URL path and database for user language settings as well, even if the app is wrapped.
Are those inserts in the app text itself? Do they have any actual ‘template’ so as to read something like {{profile_name}} or are they just empty square brackets like []?
Thanks for the plug for the plugin. There are lots of plugins that allow experienced developers make use of the power of api objects to solve a whole host of issues.
But api objects only used to solve for need to have thousands of translated text, not just for removing a flash and data reload when changing language.
@boston85719 wanted to come back to this one more time today because yesterday I was in a hurry.
An image alt text is for one thing and one thing only…to describe the image…
a blue car driving down a country road with a happy family
IF, anyone tells you that you can stuff keywords or add a title like ‘we create the best apps’, and that will help with SEO, they’re sadly mistaken and blowing smoke. It doesn’t.
So, if you take an H1 and bake it into an image, you lose that SEO possibility.
So, yes, other than the translation thing, alt text on an image should only be to describe it.
Imagine if you relied on a reader and it read ‘ we are the world’s best’, you would have no idea what the image was.
A lot of nonsense out there…it’s best to use the best practices because they’ve been tried, tested, and work
Definitely. Using alt text on an image is a best practice as it helps with image seo, accessibility and seo in general as it gives greater context to the page content…this would be why it is wise to use and to translate it as well.
And of course, use of alt text is for its specific purpose and nobody should be suggesting it is to replace an H1 used for the page’s main topic. If a site is not translating their pages main topic, that is definitely unprofessional, so any hero image at top of page with H1 text overlayed should be translated, and any section images with section titles in H2 or H3 should be translated as well. If they are also using images in main body of a section, they can add captions also.
All of these combined will make for great SEO, as accessibility is taken care of via alt text and the page seo is handled via heading tags.
