@ts11 - looks impressive. From my first reading it sounds promising. If it works, you should do a manual for the rest of us. 
Fingers crossed everything works as planned!
1 Like
Haha. If it works, I would be honored to do so. I’ll keep you posted 
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.
Hello @ts11 @sudsy ! Your thoughts on this is very valuable for building a multilingual experience. I have been working on this too and really appreciate your sharing. Regarding URL structure and content I am not sure how you want to do this. Maybe I am missing something here… So here are some questions / further thoughts about it :
- How do you differentiate the index page from the base page of your SPA ?
- If you set your Index / base page to type “language”, you would get your URL as myapp.com/en for instance, but I understand from Bubble’s constraints on URL that you could not get your example myapp.com/en/account URL because it would require a “en” page of type “page”, which should not be possible as you would have two /en pages. Correct ? And anyway it would not really be a SPA then ?
- If you go straight to creating one new page per language with a type “page”, how do you ensure the content structure consistency across pages ? Would you create all the content structure in reusable elements to avoid copying and pasting elements across language pages everytime you want to make a change ?
1 Like
I wish I could help, @jean-david, but I’ve never built a multilingual site, although I can imagine a number of ways to go about it (some of which might not be ideal SEO-wise). I mean, even Google support pages use a simple query string param to determine the language in which to serve the content. (…but then, Google is probably not too concerned about SEO) 
1 Like
I’m so sorry for overlooking this thread. I’ve not been spending as much time in the forums lately and this project, in particular, has been on hold. That said, I haven’t completed a multilingual setup myself, beyond running some proof-of-concept experiments. That said, I think I can offer some pointers. Hopefully, they’re still useful to you (though you’ve probably already answered these questions for yourself).
- I’m not suggesting a true SPA, but rather an SPA-like approach, which renders the different page modules dynamically based on the URL path.
- You are correct in observing that your index page would need to be separate from your base page. If you aren’t concerned about SEO (i.e. your app is all protected content anyway), you could just use a redirect rule on the index page to route folks to your base page.
- If you are concerned about SEO, I would imagine the most straightforward approach might be to create your index page in your primary market’s language and then duplicate this page’s content on your multilingual, base page, redirecting site visitors to the second, proxy index page only if they select a different language. Obviously, this creates some sticky SEO questions, and I’m frankly no expert there, either. But I’d imagine you could solve them by tweaking your sitemap and canonical content tags.
- Regarding the URL path, I could see two approaches. Either you could have a single, base page for each translation of your site. Each time you moved into a new market, you would just clone that base page and update the name. Not the most streamlined approach, obviously, but how likely is it that you’ll need your site translated to every language right away? Entering new markets is still pretty trivial this way. The second approach would be to have a typed page, as you referenced in your post. With this approach, you’d just name your page something like “l,” and your URL paths would be a little less elegant (i.e. “myapp.com/l/en/page”).
- Regarding your final question, yes I would advise creating your content modules in reusable elements. If you really want to go crazy, I’d toy around with using reusables in conjunction with repeating groups and conditional visibility rules to generate your page layouts on the fly. That’s where things get really interesting.
Hope this helped a bit! Let me know how the project is going.
Cheers,
TS
1 Like
The filter should also take into account placement used.
- Page
- Element
- Component types
This makes it possible to filter out all texts for one page and work them.
I have created this for another application years ago in .Net.
Every text had the following attributes:
- ID key (the selector)
- Description
- Page
- Module
- Language
- Text
Description used whenever a more comprehensive explanation is needed.
Page-module-id identifies a text used in any element. Depends on application size if this is needed.
BUT: What I really miss in Bubble is an Excel style editor for these texts. When using a professional translator for several languages, an Excel table is the absolute most efficient way of entering texts. They work across all languages at the same time.
And I would like to have another addition to the suggested changes. The App-text should be shown on the component in editor-mode, not the key-phrase. This messes with the perceived design. Previewing is just too slow. A small “tag” of some sort could show that the text is from APPText. The Key-phrase could be a tooltip. And the “tag” could trigger an inplace-editor for the text you are viewing, kind of like what has already been suggested.
Efficiency and ease of use is king!
1 Like
So, what is the status of this really?
I’m a bit new to this forum, so forgive me if I haven’ t found everything, but does there exist a project development task-list with possibility to vote?
regards
Alexander
Welcome to the community.
I enjoyed hearing your thoughts.
Yes, Bubble has an idea board now, but it was made much, much later than this post, and I didn’t move the ideas here. Still, great ideas are waiting to be voted on.
Best,
Eren
I also would like to have the possibility to use App Text(?) in this manner:
App Text()
This makes it possible to create data-driven applications and menues, and still use the buildt in App Text functionality for labels.
EX: App Text(MenuOptions’s MenuItem) evaluates to something like
App Text(MENUITEMTEXT_ID1)
@eren
I want to copy the whole list of App text from another file. When i export the bubbles CSV file i was not able to add items to the list.
For import any specific file format supported.