On WordPress, running Universally takes no code: install a plugin, connect it with an API key, pick languages. Everything past that basic setup varies, so this page lists which tasks need what, and where you would need someone else.
What the WordPress setup needs
Three things, none of them code:
- WordPress 6.0 or later and PHP 7.4 or later. Check under Tools » Site Health » Info if you are not sure. Most hosts are already past both.
- An administrator account on the WordPress site. Editors and authors cannot install plugins.
- The plugin zip from your project's WordPress Plugin page, uploaded through Plugins » Add New.
See Install on WordPress for the walkthrough.
What you can do from the dashboard alone
No code, no theme files, no command line:
| Task | Where |
|---|---|
| Add and remove languages | Add and remove languages |
| Keep brand names untranslated, or fix a term's translation | Glossary rules |
| Exclude a page, or a whole URL pattern, from translation | Exclude pages |
| Fix a specific translation by hand | Edit translations manually |
| Float the language switcher in a page corner | Place the language switcher |
| Change the switcher's colours, size and labels | Style the switcher |
Choose the URL segment for a language, /fr/ or /ca/ |
Add and remove languages |
| Invite people and set what they can change | Roles and permissions |
Where some technical comfort helps
These do not need a developer, but they do need more than clicking:
Putting the switcher somewhere specific. Setting Implementation to Custom gives you a shortcode, a block, and a PHP snippet. The shortcode and block need no code knowledge. The PHP snippet goes in a theme template, and it belongs in a child theme so a theme update does not wipe it. See Place the language switcher.
Excluding part of a page rather than a whole page. This is done with CSS selectors, so you need to open your browser's element inspector and work out what identifies the thing you want left alone. See Include and exclude CSS selectors.
Checking that translation is actually working. Visiting a translated URL and reading the page source is the fastest way to tell a translation problem from a caching one. See Verify your installation.
Where you need a developer
A site that is not on WordPress, for now. Other platforms connect through the REST API: your server sends the rendered page and serves back what it gets. It is a piece of server-side work rather than an install, and native integrations for more platforms are being built, so this is a question of timing rather than of whether Universally fits. See Integrate using the API and Supported platforms.
Headless setups. A decoupled front end has to call the API itself. See Use Universally with a headless CMS.
Content that appears after the page loads. Text a script inserts once the page is in the browser is sent through the API by your own code. Coverage for dynamic content is being expanded. See Translate dynamic and JavaScript content.
A sitemap listing the translated URLs. On WordPress the metadata and the hreflang alternates are handled for you, but submitting translated URLs in a sitemap is still whoever manages your sitemap. See Multilingual SEO overview.