How to Set Up a Client Portal Where Each Client Sees Content in Their Language
Create a custom user role per client or language group, then use a translation plugin with role-based visibility so each client only sees their own language. The steps below walk through WordPress roles, a...
To set up a client portal where each client sees content in their language, create a custom user role per client or language group, then pair it with a translation plugin that supports role-based visibility. Each client logs in, the system checks their role, and only the content assigned to that role shows up in their language. The rest of this guide walks through the exact steps, the trade-offs, and one verification check at the end.
What a role-based multilingual client portal actually does
A role-based portal treats language as a property of the user, not the browser. Two clients can log in from the same country, but each one sees a different set of pages in a different language. The portal hides pages that do not belong to that role, so a French client never sees the English draft, and an English client never sees the Spanish version.
This setup is different from a public multilingual site. On a public site, the visitor's browser language or a language switcher decides what they see. In a client portal, the logged-in user's role decides. That matters when you handle private documents, contracts, or reports that should never leak across clients.
Prerequisites before you start
- A WordPress site with admin access.
- A user management plugin that lets you create custom roles, or the built-in role editor plus a role-management add-on.
- A translation plugin that supports per-role or per-user content visibility.
- A clear list of which clients get which language, and which pages each client should see.
Sort the client list first. If you skip this step, you end up assigning roles one by one later and lose track of who sees what.
Step-by-step setup
Step 1: Plan your roles and languages
Open a spreadsheet. List every client, the language they need, and the pages or documents they should access. Group clients who share the same language and the same content set. Each group becomes one custom role.
For example, a design agency might have:
- Role: client-en — sees English project pages.
- Role: client-fr — sees French project pages.
- Role: client-es — sees Spanish project pages.
Keep the role names short and predictable. You will type them many times.
Step 2: Create a custom user role per language group
In WordPress, go to Users → Roles (or use a role editor plugin). Add a new role for each language group. Give it only the capabilities a client needs: read pages, read private pages, download files. Do not give clients editing or publishing rights unless they truly need them.
Then create a user account for each client and assign them to the matching role. Test with one account before you bulk-create the rest.
Step 3: Turn on a translation plugin with role-based visibility
Install a translation plugin that lets you tie translated content to a specific role. SEATEXT, for example, detects each visitor's language and translates WordPress pages automatically, then keeps new posts and updates translated in the background. Pair that automatic translation with role-based page visibility so each role only sees the pages you assign to it.
Activate the plugin, connect it to your site, and pick the languages you need. The plugin should let you mark a page as visible to a specific role, not just to a language.
Step 4: Tag each page with the right role and language
For every page or document in the portal, set two things:
- The role allowed to view it.
- The language the content should appear in for that role.
If you use SEATEXT, publish the page once and let the plugin translate it. Then restrict visibility to the matching role. A French client logs in, the plugin serves the French translation, and the page only loads if their role matches.
Step 5: Build the login and redirect flow
Clients should land on a portal page, not the public homepage. Use a login redirect plugin to send each role to a portal landing page in their language. The landing page lists the documents, projects, or files that role can access.
Hide the admin bar for client roles. Most clients do not need to see WordPress menus, and the bar leaks information about your site setup.
Step 6: Verify the setup before you onboard clients
Log in as each test role in a private browser window. Check three things:
- The portal page loads in the correct language.
- Pages meant for other roles return a 404 or "not allowed" message, not a translated version.
- New content you publish gets translated and assigned to the right role automatically.
If a French client can see an English page, the role restriction is missing. If they see the right page in the wrong language, the translation plugin is not tied to the role.
Key facts about this setup
| Item | Detail |
|---|---|
| Core mechanism | Custom user role per language group, paired with role-based page visibility |
| Translation method | Automatic plugin translation, kept in sync as new content is published |
| Languages supported | Up to 125 languages with SEATEXT |
| Content control | Each role only sees pages assigned to it; other pages stay hidden |
| Best fit | Agencies, law firms, consultancies, and service businesses with private client material |
| Common mistake | Translating by browser language instead of by logged-in role |
Common mistakes and how to avoid them
Translating by browser language. A French client using an English laptop will see English content if you rely on browser settings. Tie language to the user role, not the browser.
One role for all clients. If every client shares the subscriber role, you cannot hide pages per client. Each language group needs its own role.
Forgetting new content. When you publish a new page, the translation plugin must pick it up and the role restriction must apply. Test the workflow with a draft before you go live.
Giving clients too many rights. Editors and admins can see drafts, plugin settings, and other clients' pages. Client roles should only read what they need.
When this setup is the wrong choice
If your clients do not log in and you only need a public multilingual site, role-based visibility is overkill. Use a standard multilingual site with a language switcher instead.
If you have hundreds of clients and each one needs a unique document set, custom roles per client become hard to manage. At that scale, look for a portal tool with per-user document sharing, such as the no-code portal builders in the search results, and add translation on top.
If your content changes daily and you translate by hand, the manual work will block you. Use automatic translation so new pages get translated without a ticket.
Practical scenarios
Design agency with 12 clients. Three languages, four clients per language. Create three roles, assign each client, and let the translation plugin handle the language layer.
Law firm with private case files. Each client sees only their own case documents. Use one role per client, restrict every document to that role, and translate the visible content into the client's language.
Consultancy with shared resources. All clients see a common resource library, plus private project pages. Create a base client-base role for the library and per-language roles that inherit from it.
Limitations to keep in mind
Role-based portals do not stop a logged-in user from sharing a link. If a client forwards a private URL, the recipient sees the content if they also have access. Use expiring links or per-user tokens for sensitive material.
Automatic translation works well for standard content, but legal or medical text needs a human review. Plan for a review step on high-stakes pages.
Plugin-based translation depends on the plugin staying active and connected. If you deactivate it, clients see untranslated content. Keep the plugin updated and monitor its status.
Frequently asked questions
Do I need a separate WordPress site for each language?
No. One site with role-based visibility and a translation plugin handles every language. Each role sees only the pages assigned to it, in the right language.
Can I use this with WooCommerce or a learning platform?
Yes, as long as the plugin supports the content type. SEATEXT translates pages, posts, products, and updates automatically, so it covers most WordPress content.
How many languages can I support?
SEATEXT supports up to 125 languages. The practical limit is how many custom roles you want to manage. Group clients by language to keep the role list short.
What happens when I publish a new page?
The translation plugin detects the new page, translates it into the languages you enabled, and applies the role restriction you set. Clients in the matching role see it on their next login.
Can clients switch languages inside the portal?
Only if you give them access to more than one role. By design, each role sees one language. If a client needs two languages, assign them to two roles and let them pick the portal landing page.
Is this secure enough for contracts or medical records?
Role-based visibility hides pages from the wrong users, but you still need HTTPS, strong passwords, and expiring links for sensitive files. Translation does not replace document security.
How long does the setup take?
For a small agency with three languages, plan two to four hours: one hour to plan roles, one hour to create them, and the rest to tag pages and test logins.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.