--- title: Moj Clone Script: Running One Short-Video Build Across Many Languages description: "How a Moj clone script runs many languages from one deployment: the language table, translation CSVs, what localizes, and what stays scoped work." url: https://miracuves.com/blog/moj-clone-script-multi-language-localization date_modified: 2026-10-23 author: miracuves language: en_US --- ### Key Takeaways - A **Moj clone script** handles many languages the way most production short-video builds do: one deployment, one database, and a per-language translation file that swaps interface copy without touching code. - The whole mechanism is a single table with six columns, a CSV file per language, and five admin actions. Understanding those is enough to plan a multi-locale launch accurately. - The translation layer covers interface copy only. It does not translate captions, comments, or anything a creator posts, and no documented feature does. - Right-to-left layout does not appear anywhere in the platform documentation. Treat it as scoped engineering work, not a switch you flip in an admin panel. - Several things stay single-valued no matter how many languages you enable: currency, legal pages, app name, and the onboarding slides shown before a user has chosen a language. - One instance serving many languages is the opposite of multi-tenant. Multi-tenant is explicitly out of scope, and the two decisions should never be confused. ## What does “one build, many languages” actually mean? Founders planning a short-video launch across more than one language usually ask the question backwards. They ask how many languages the platform supports, when the useful question is which layers of the product localize and which do not. The answer to the first is “as many rows as you add.” The answer to the second is a short, specific list, and that list decides whether a launch in a second market feels finished or half-translated. The [Moj clone](https://miracuves.com/moj-clone/) platform follows a pattern that is common in production Flutter and Laravel builds: a single Laravel API serves both the mobile app and the web surface from one MySQL database, and language is handled as data inside that one deployment rather than as a separate build per locale. That single detail drives everything else in this article. There is no per-language binary, no per-market codebase, and no separate instance per country. There is one running system, and a table that tells it which languages exist. That design is a real advantage with real edges. Adding a locale is a content operation rather than a release, but anything stored as a single value in that one database stays a single value for every language at once. Most localization disappointment in this category comes from not knowing which category a given piece of text falls into, so the rest of this piece walks the layers one at a time. ## Where does the language list live in a Moj clone script? In a single table called `languages`. It is worth looking at its columns, because the table is the entire localization model and nothing is hidden behind it: - `code` – the short language code, for example `en`. - `title` – the language name as your team refers to it. - `localized_title` – the language name written in that language, which is what a user scanning a language list actually recognizes. - `csv_file` – a path to that language’s translation file. - `status` – whether the language is live. - `is_default` – whether it is the fallback language for the deployment. Six columns. That is the whole data model for multi-language support, and its simplicity is the point. A language is a row, a translation set is a file referenced by that row, and the app reads the available languages from the backend rather than from anything compiled into the installed app. The documented requirement states that sequence directly: the language list comes from the backend, the translations come from CSV, and the user picks one. Two of those columns do more work than they appear to. `localized_title` exists because a user who only reads Marathi should not have to find “Marathi” spelled in English in order to switch to it. And `status` is what makes a staged rollout possible: create the row, attach a partly finished CSV, and leave the language switched off until the translation is complete. Nothing forces you to expose a language the moment you create it. ![Mobile settings screen linking premium access, creator subscriptions, business dashboard, creator fund, and creator advertising tools](https://miracuves.com/wp-content/uploads/2026/05/setting_screen-461x1024.webp "Moj Clone Script: Running One Short-Video Build Across Many Languages 1")Image Source: Miracuves product screenshot. ## What does the translation CSV actually translate? Interface copy. That is the honest and complete answer, and it is the single most important sentence in this article. The documentation describes one translation CSV per language, used so that the operator can add or change copy without code. That covers the text the product itself owns: button labels, screen titles, menu items, validation messages, empty states, the words around the video rather than the video. Change a line in the CSV and the label changes in that language. That is a genuinely useful capability, and for the interface layer it does what it says. What it does not touch is everything users create. A caption written in Hindi stays in Hindi for a viewer whose interface is set to Tamil. Comments are not translated. Hashtags are not translated. Video audio is not translated. There is no documented feed filter, region filter, or language filter that would show a viewer only the content matching their chosen interface language, and no documented auto-translation anywhere in the platform. The two are easy to conflate in a pitch deck and impossible to conflate in production. “The app is available in eight languages” and “users in eight languages can understand each other’s content” are completely different products. The first is a CSV file. The second is a translation pipeline nobody has built here, and assuming the first delivers the second means discovering the gap after launch, in a market where the interface reads perfectly and the feed does not. ## How do you add a language without shipping a new app release? Through the admin panel, using a small set of documented actions. The admin requirement names four directly – list languages, add a language, update a language, and set the default language – and the feature inventory adds the rest of the lifecycle: delete a language, toggle a language on or off, and upload or edit the translation CSV. Put together, that gives a repeatable sequence for entering a new linguistic market: - Add the language row with its code, title, and localized title, and leave it disabled. - Upload the translation CSV for that language. - Review the interface in that language internally while the row is still switched off. - Enable the row, which makes the language selectable by users. - Optionally make it the default, which changes what new users see first. The operational value is easy to underrate: because the list is served from the backend, none of those five steps requires an app store submission or a review cycle. A copy correction in your second language is a CSV edit, not a release train. For a team testing demand in a new market, that compresses the feedback loop from weeks to the same afternoon. One caution worth stating because the documentation does not: there is no described behavior for a key that exists in the interface but is missing from a language’s CSV, and no described validation on the CSV at upload. Neither absence is dramatic, but both make the review step above non-optional. Walk the screens with the row still disabled, rather than finding the gaps in your app store reviews. ## Which layers of the product actually localize? This is the table to take into a planning meeting. Each row maps a layer of the product to the mechanism the documentation describes for it. “Single-valued” means one value in the database serving every language at once. | Layer of the product | Documented mechanism | Changeable without a release? | What a founder must plan for | | --- | --- | --- | --- | | Interface labels and screen copy | Translation CSV, one per language row | Yes – edit or re-upload the CSV | Key coverage; no documented fallback for a missing key | | The language list itself | `languages` rows; list served from the backend | Yes – add, update, enable, set default | Stage with `status` off until the CSV is reviewed | | Onboarding slides | Rows with one title and one description each | Yes – admin edit | Single-language slides, shown before the language is chosen | | App name and legal pages | Single-row settings fields | Yes – admin edit | One privacy policy and one terms text for every locale | | Currency display | A single `currency` value in settings | Yes – admin edit | One currency for all languages, not one per language | | Admin-entered catalogs such as report reasons | A single title column per row | Yes – admin edit | Single-language text appearing inside a translated screen | | Captions, comments, and video content | Not covered by any documented mechanism | Not applicable | Untranslated; handle editorially or through creator guidelines | | Right-to-left layout direction | Not present in the documentation | No | Scoped engineering work, quoted and built deliberately | Read the right-hand column as your actual localization backlog. The rows that say “yes” are configuration. The last two rows are the ones that need a decision and a budget. ## Where does the language choice sit in the user journey? At the end of first-launch onboarding. The documented flow runs through the onboarding slides and then arrives at the language and login step, and the new-user journey describes the same order: the slides introduce the app, then the user selects a language. There is a consequence in that ordering that deserves to be said out loud, because it is visible to every new user in a non-default language and invisible in a feature list. The onboarding slides are database rows with one title and one description each. They are not CSV keys. So the screens a user sees immediately before choosing their language exist in exactly one language: whichever one you wrote them in. Write them in the language of your largest market and keep the text short enough that imagery carries most of the meaning, or treat localized onboarding as a scoped change to how those rows are stored. What you should not do is assume the CSV reaches those screens, because it does not. The second detail in this part of the journey is a surface asymmetry. The feature inventory lists which surfaces each capability appears on, and for selecting a language it marks the mobile app and leaves the web column empty. The language picker is documented as an app feature, as is the onboarding sequence leading into it. For a short-video product that is usually a smaller problem than it sounds, because the app is where the product lives. But if a meaningful share of your second-language traffic arrives on the web through shared links, you are choosing between a scoped addition of language selection to the web surface and a web experience that stays in the default language while the app localizes. Either answer can be right; choosing it on purpose before the build is the part that matters. ![Short video platform explore page displaying trending content categories, media thumbnails, search functionality, and content discovery grid](https://miracuves.com/wp-content/uploads/2026/05/Explore-1024x505.webp "Moj Clone Script: Running One Short-Video Build Across Many Languages 2")Image Source: Miracuves product screenshot. ## What happens with right-to-left languages? Nothing is documented, and this is important enough to state without softening. The platform documentation set runs to 45 files covering requirements, features, the data model, the schema, the API collection, security review, and the individual engineering work items. Searching all 45 for right-to-left support returns no results: no mention of RTL, no mention of right-to-left, no bidirectional text handling, no text-direction setting, and no reference to any right-to-left language. The capability is not described as present, not described as partial, and not described as planned. What that means in practice is that RTL is scoped engineering work rather than a feature you enable. Adding a language row with an Arabic or Hebrew code will give you a selectable language and a translated string set. It will not mirror the layout, flip directional icons and navigation, correct alignment in text fields, or handle mixed-direction strings where a Latin username appears inside a right-to-left sentence. Those are real changes across the interface, and they need to be quoted, built, and tested as such. We are explicit about this because the alternative is worse. Promising RTL on a platform that has not shipped it produces a launch where the strings are right and the product is visibly wrong, in markets where that reads as carelessness rather than as a missing feature. If a Gulf or Levant market is in your first year, scope RTL as a line item at the start, with a budget attached. Never assume it arrives with the CSV. ## Can the platform translate what creators post? No, and the documentation is unusually clear about why, which makes this easy to plan around. There is an automatic subtitle capability in the platform’s optional feature packs, built on a self-hosted speech recognition engine so that it can run without a paid transcription account. Two facts about it govern any localization plan. The first is that the auto-subtitle pack is off in the delivered configuration, so it is scoped work to enable and operate rather than something running on day one. The second is more fundamental: the engineering notes list “no translation” as an explicit ceiling of that component. It transcribes speech in the language that was spoken. It does not convert it into another language. So even with that pack fully enabled and running, a Bengali video produces Bengali captions, not Tamil ones. Subtitles are an accessibility and silent-autoplay feature here, which is a good reason to want them. They are not a cross-language bridge, and the same documentation lists other honest limits alongside the translation one, including no speaker labels and no word-level timing. If crossing the language barrier inside the content itself is central to your product thesis, that is a separate build on top of this foundation and should be planned and priced as one. It is an achievable addition. It is not an existing feature. ## One instance serving many languages is not multi-tenant These two ideas get collapsed into each other constantly, and they are close to opposites. Keeping them apart will save you an expensive architectural wrong turn. Multi-language means one deployment, one database, one brand, one community, and a translated interface wrapping all of it. Every user is in the same product and the same feed; they simply read the furniture in different languages. That is what this platform does, and the reason it can do it cheaply is precisely that there is only one of everything underneath. Multi-tenant means one codebase serving several separate brands, each with its own users, content, and isolation boundaries. It is a materially different architecture, and on this platform it is explicitly out of scope: one deployment is one brand. If you need two distinct brands, you are running two deployments, not configuring two tenants. We have written separately about [multi-tenant short-video platforms](https://miracuves.com/blog/multi-tenant-short-video-platforms/) and what that architecture actually costs, and it is worth reading before you decide you need it. The distinction belongs in a localization article because founders often reach for multi-tenancy to solve a problem that is really about language. “We need a separate instance for our Spanish market” is usually a language row and a default setting, not a second deployment with its own database, operations, and split community. Serving many languages from one instance is cheaper and often the better product, since one community at the scale of all your markets beats several small isolated ones. Reach for a second deployment when you need a second brand, not a second language. ## What stays single-valued no matter how many languages you enable? The flip side of one instance serving everyone is that the configuration serving everyone is also singular. The platform’s settings live in a single-row configuration table, which has a direct and sometimes surprising consequence: the app name, the default currency, the privacy policy, and the terms of use are one value each, shared by every language you run. Three implications are worth planning for explicitly: - **Currency is global, not per-language.** There is one currency value for display. Enabling a second language does not create a second price presentation, so if your markets need different currencies, that is scoped work rather than configuration. - **Legal text is one document.** The privacy policy and terms are single fields of content. Translated legal pages, where a market requires them, are a scoped addition and usually a legal review as well, not a CSV row. - **Admin-entered catalog text is not CSV-keyed.** Items your team types into the admin panel, such as report reasons, are stored as a title on a row. They will appear in whatever language they were typed in, inside an otherwise translated screen. It is a small thing that looks sloppy if nobody has thought about it. There is one further gap worth naming plainly, because it only becomes visible in production. The user table carries no language column. The chosen language is a client-side selection, and the documentation does not describe the backend storing a per-user language preference. Server-generated text, push notifications in particular, therefore has no documented per-user language to render in. The country code attached to a phone number is not a language preference and should not be treated as one. If localized push messaging matters to your retention plan, treat storing a per-user language as part of the scope rather than assuming it is already there. ## Founder Decision Signals A few signals that reliably tell you which localization path you are actually on: - **Your markets share a script and read left to right.** The documented CSV mechanism covers most of what you need. Budget translation and review time, not engineering time. - **A right-to-left market is in your first year.** Scope RTL at the start as explicit engineering work with its own testing pass. Do not let it become a late discovery. - **Your thesis depends on users understanding content across languages.** You are planning a translation pipeline on top of this foundation. Price it separately and honestly, and do not count the subtitle pack as a head start on it. - **Different markets need different prices or currencies.** One currency value is configuration; several are scoped work. Decide before the build, not after your second market launches. - **You are tempted by a second deployment “for the Spanish users.”** That is almost always a language problem wearing an architecture costume. Add the rows first. - **Legal review differs by market.** Plan for translated legal pages as a scoped change, with the lawyer’s time in the timeline alongside the developer’s. - **Most of your second-language traffic will arrive on the web.** Language selection is documented on the app surface. Decide deliberately whether web localization is in scope. ## Common Localization Mistakes to Avoid These are the recurring ones, and all of them are cheap to avoid and expensive to discover late. - **Selling a translated interface as a translated platform.** The CSV covers the product’s own copy and never touches captions, comments, or audio. Keep the two claims apart in your marketing, because users will keep them apart in their reviews. - **Assuming RTL comes free with the language row.** It does not appear in the documentation at all. A language row gives you strings, not a mirrored layout. - **Enabling a language before the CSV is reviewed.** The `status` column exists precisely so you do not have to. Stage, walk every screen, then enable. - **Forgetting the onboarding slides.** They are single-language rows shown before the user picks a language. Every new user in a second market sees them. - **Translating the interface and leaving admin-entered catalogs untranslated.** Report reasons and similar lists are typed text on rows, not CSV keys. - **Planning localized push notifications without storing a language.** There is no documented per-user language column for the server to read. - **Reaching for multi-tenancy to solve a language problem.** One deployment is one brand. Many languages fit comfortably inside one deployment. - **Launching ten languages at once.** Each needs translation, review, and ongoing copy maintenance as the product changes. Two done well beat ten done approximately. ## How a Ready-Made Foundation Fits a Multi-Language Launch The argument for starting from a built foundation is strongest exactly where localization sits, because localization is tedious rather than clever. The language table, the per-language CSV loading, the admin lifecycle for adding and defaulting a language, the backend-served list that lets you add a locale without a store release: none of it is interesting to build, all of it takes time, and all of it is already here and documented. What that buys is not just the saved weeks but a known shape. Because the mechanism is a single table and a CSV per row, you can plan a language rollout precisely rather than hopefully, and tell configuration apart from engineering before committing a timeline to anyone. The table earlier in this article is the planning artifact: the rows marked “yes” are a content task for your team, and the last two rows are a conversation with your engineers. At Miracuves we build on this foundation for founders entering more than one linguistic market, and on localization we separate the two columns before anyone writes code. Configuration goes in the launch checklist. RTL, per-market currency, translated legal pages, web-surface language selection, per-user language for push, and any cross-language content translation go in a scope document with effort attached, so the thing you approve is the thing you receive. Our wider work here sits under [media and entertainment](https://miracuves.com/industries/media-entertainment/), and the platform under our [video content platform](https://miracuves.com/solutions/entertainment/video-content-platform/) solutions. We would rather tell you that right-to-left layout is scoped work than let you find out after launch. A foundation is worth having because it is known, and a known gap you have budgeted for costs a fraction of a surprise you have promised a market. ## Final Thoughts Running one short-video build across many languages is a solved problem at the interface layer and an open question everywhere else. Six columns in a table, one CSV per language, and a handful of admin actions will carry you into a new linguistic market without a release cycle. For most teams entering a second or third language, that is enough. What will not carry you is the assumption that localization is a single switch. The feed stays in the language it was posted in. Currency and legal text are one value each. The onboarding slides are written once. Right-to-left layout is not in the documentation at all, and the transcription component does not translate. None of these is a flaw in the foundation. They are its edges, and edges you can see are the ones you can plan around. So treat your language rollout as two lists. The configuration list belongs to your content team and starts the day the build is handed over. The scope list belongs in your budget before the build begins. Founders who draw that line early launch in their second market on schedule. Those who do not tend to launch twice. ## FAQs ### How many languages can the platform support? There is no documented limit, because a language is simply a row in the languages table with a translation CSV attached. The practical limit is how many translation sets your team can produce and maintain as the product changes. Most founders are better served launching two or three well than ten approximately, since every language needs review each time the interface copy changes. ### Does multi-language support mean users see content in their own language? No. The translation mechanism covers interface copy only: labels, buttons, screen titles, and messages. Captions, comments, hashtags, and video audio stay in whatever language the creator used, and there is no documented feed filter or auto-translation that would change that. The interface localizes; the content does not. ### Does the platform support right-to-left languages such as Arabic? Right-to-left support does not appear anywhere in the platform documentation. You can add an Arabic language row and a translated string set, but mirrored layout, flipped directional icons, text-field alignment, and mixed-direction strings are not described as implemented. Treat right-to-left as scoped engineering work with its own build and testing effort, not as a setting you enable. ### Can we add a new language after launch without an app store release? Yes, for the interface layer. The language list is served from the backend rather than compiled into the installed app, so adding a row, uploading its CSV, and enabling it are admin operations. That is also why a copy correction in a second language can ship the same day instead of waiting for a review cycle. ### Can we charge different prices in different markets? Not through the language mechanism. The platform settings hold a single currency value used for display across the whole deployment, so enabling a second language does not create a second price presentation. Per-market currency or pricing is scoped work, and it is much cheaper to specify before the build than to retrofit after a second market has launched. ### Will the onboarding screens appear in the user’s language? No, and this one catches teams out. The onboarding slides are stored as rows with one title and one description each, so they exist in a single language, and the documented flow shows them before the user chooses a language. Write them in your largest market’s language and keep the text short, or scope localized onboarding as a deliberate change. ### Do automatic subtitles translate a video into other languages? No. The automatic subtitle capability is an optional feature pack that is off in the delivered configuration, and its documented ceilings state plainly that it does not translate: it transcribes speech in the language spoken. Subtitles are useful for accessibility and silent autoplay, not as a bridge between languages. Cross-language content translation is a separate build. ### Do we need separate deployments for each language or country? No, and doing so is usually a costly mistake. One deployment serves many languages from a single database, which is the whole point of the design. Separate deployments are for separate brands, since multi-tenancy is out of scope and one deployment is one brand. A second language is a few rows and a default setting, not a second instance with its own database, operations, and split community. ## Disclaimer **Miracuves is an independent software development company.** We are not affiliated with, connected to, sponsored by, or endorsed by any of the brands or platforms named on this page. Names of the form “Brand Clone” are used descriptively: it is how the software industry refers to building a platform with functionality comparable to a known service, and how clients search for it. The entire design and codebase of our products is built by our own team and contains no code, design, graphics, or content originating from any third-party website or application. All third-party names and marks are the property of their respective owners. [Full Legal Notice & Disclaimer](https://miracuves.com/disclaimer/)