Using multisite is also good because it’s not so widely used and in this way it will also be a good test platform.
2 Likes
From a translators perspective the workflowis as follows: a Multisite is created, and people translate the original site by means of things like matecat (you copy original text to files, then upload to matecat and specify origin and target language and it assists with translation, the person reviews everything and then downloads, to upload in the subdomain).
This implies that the person doing the job needs to know the origin language and be native in the target language.
What plugins for translation do is adding custom fields to each post and this means duplicating content in all languages on same site. It’s very bad in terms of managing it AND in terms of SEO. Basically it means that all locales of a post get indexed all together as a big soup.
Having subdomain s helps with SEO. Each locale team handles only their locale. If one site encounters an issue all the others are ok.
Usually a website stays within the 20k worlds or less on average. One translator alone does that in 5 days average with a cat tool like matecat. Then it’s a matter of keeping the blog posts translated when they come out because the static part stays the same. Keeping the blog localized means that each post gets passed to localizers and the every site publishes it at the same time.
EDITED TO ADD: the not so easy part is having a team for each subdomain, at present we have mostly English speaking natives, some Italians and some Germans if I am not mistaken. We can certainly start with Italian but I think there’s not much need to localize the main site for now. WP started localizing docs and site very late preferring to focus on other things. I worked on localization when I was there.
It’s very important that the localizers be native in the target language. An American can’t translate to German of French. So I suggest starting to localize only for the locales we have native speakers for. Things like docs take priority over the main site however IMHO.
I don’t see how we can do docs before main site, because the way we do the main site will potentially affect the URLs of all other CP sites.
This is also why it’s important to get this done sooner rather than later. Otherwise we’ll end up with a redirection nightmare.
As for the relevant teams, we simply start with what we have. Then those sites will become a model for other languages, and those who work on the first sites can give the benefit of their experiences to those offering to do the later sites.
1 Like
We need to update main website content. There’s a lot of outdated info. This can be paired with migration to multisite instance. I can work on this, using a staging website. Once English version is complete, we can focus on one language to get the process right. It can be Italian, if @ElisabettaCarrara can help. German would be good, too. Lots of websites using German on their CP websites, from what I remember doing log analysis.
1 Like
Me thinks Italian has not many users. But we can start with that.
To translate I would need files (pdf, google docs, odt, doc really whatever) with the texts that need translating (posts, pages titles, tags, categories).
The real issue is SEO
Every locale needs a SEO analysis all along the translation.
I am not a SEO pro, but if we know the keywords the site is indexed for I can try to work with that.
(And don’t tell me the site was never optimized for SEO because this is totally another can of worms, and really takes priority over translating it).
SEO is really not something to focus on at all. That would be the tail wagging the dog. Google’s main ranking factor is content: lots of related content. If we have that (and we will) and it doesn’t simply duplicate WP’s (which, apart from the docs sites when we get to them, it won’t), and the sites run fast (another important factor), then we’ll be fine with SEO.
3 Likes
used one database but multiple tables prefixed
@notelseit this means giving the main site keys to MANY PEOPLE that need it to translate.
instead with a multisite each group of translators manages ONLY one subdomain, and the multisite super admin can totally intervene if something wrong happens.
basically multisite has tables for each site and keeps things separate, which is also good. a single site with prefixed tables is just a soup.
Just to be clear, the options are:
-
Multisite: one database with one table for all users but separate tables for each subsite, which would appear as a subdomain, or
-
A single site in English, and then a single site for each other language for which we offer a translation (again appearing as a subdomain). This one means that users are not necessarily shared across sites because each site has its own database with its own users table. It does not need specially-prefixed tables because those tables are built-in to each site anyway.
1 Like
Wouldn’t it be easier managing a Multisite?
My vote is for multisite:
- One instance of CP to manage (updates)
- One set of theme files, means we make an edit and it applies to all websites
- One set of users across all sites means anyone can help anywhere, maybe not with translation but with formatting, etc. without needing to log in into multiple websites with multiple passwords.
4 Likes
I don’t have experience of managing multisite on a production site (just localhost tinkering) but this one seems a big plus to me:
One set of users across all sites means anyone can help anywhere, maybe not with translation but with formatting, etc. without needing to log in into multiple websites with multiple passwords.
The fewer accounts and passwords we all need, the better, and it’s much easier for admins to just change permissions for specific subsites than it is having to create whole new accounts on new sites.
1 Like
- Users can be separated not necessarily they must have access to all the sites you can decide which ones to assign them to, example geltrude who translates german can enter the admin side only on the german subdomain but not in the italian one, while nicola who knows italian and german can enter the German and Italian site but not the English one, while admin can enter wherever he wants or even francesco having a shared user on all sites … in practice with the permissions you can decide who does what and where
- Personally I have experience in managing multisites I have lost count of how many I have made, including magento, joomla, mambo, wordpress as well as server management and I can easily help
I’d lean towards a multisite setup for this. Most of the available translation plugins (to be clear I mean plugins to power functionality and not to translate the content) are built to operate in multisite. One codebase, one data source, single site as a source of content for translation.
Multisite can work with either subdomain configurations or with sub-directories however we would be limited to subdomains. Sub-directories are only available to use for new WordPress installs to avoid any possible slug/url conflicts.
Making the entire cp.net site translatable is a pretty large ask though. There’s a lot of testing to be done on it as well as a fairly sizable amount of code changes and probably custom code needed to be written (because most things aren’t multisite compatible out of the box). That would only cover the technical part of it, there is still the question of the content. What needs to be translated, who can do it, and how many different languages could we get out?
I would also like to propose that any translated content requires at least 2 people to do it. One to translate it and another to check it. Without a 2nd person at a minimum, we would never know if the content was translated accurately or appropriately.
2 Likes
I would not use plugins to translate.
I would just have text to files and use a cat tool. Then upload directly the translation.
Translation plugins might stop working with CP.
And my suggested course of action can integrate as many translators and reviewers as needed.
For example matecat allows to segment a text and assign it to several translators. When done several reviewers can check their job before downloading text and uploading it to the site.
I had never heard of MateCAT till today but it looks like it’s a machine translation system at its root. Is that different to using a plugin to power translations that sends the content off to some service for machine translation? Am I misunderstanding what MateCAT is for?
Matecat is a tool for translators. It works outside the site. This means no crappy plugin on site, no fuss, no “doesn’t support WP 4.9 any more” and moreover translation plugins do custom fields where YOU have to input translated content. They don’t assist with translation.
Matecat instead assists with translation with the connection to latest APIs tapping in the more devoted translation AI like the engine of Google translate and others.
The only downside to matecat is you need the text in a file, so who writes the staging site has to copy paste all the text in a file.
As I previously mentioned by using that in about a week you can have all site translated, while without you need 15 days minimum.
Cat tools like matecat (or omegaT) are what translators professionally use for their work. They only barely assist with translating content roughly so there’s a need for a translator to translate every string by checking each one individually and then reviewers need to see all the strings again. But it makes working on a project faster and really effective with no complex things to learn.
We don’t need a crappy plugin with custom fields done the wrong way that it’s not even assisting in translation. We need something that works.
Seems like for now you would simply put a Google Translate button on every page and be done.
I get it now. It’s just one part of the whole setup needed. It’s an offsite translation engine that provides translation aids to someone that is capable of translating a piece of content.
I’d encourage you to look at some of the plugins that are available. I don’t think what they do is quite what you are expecting. They aren’t all crappy field-filling exercises with no translation aid. WPML and Weglot I’ve used before and been mostly happy with what they do.
They all provide facilities to handle the content and as an optional feature can pass the content between sites and services with whatever degree of translation you were wanting, either automated, partially automated or completely manual.
Any solution will still need to use custom fields and taxonomies for technical and organisational reasons - even if the solution decided on is to use MetaCAT. For example, a translated post would have to store the language it is in, somewhere to hold the original canonical URL, and the last date of translation in case of origin changes. These are just a few things that would be needed off the top of my head, I am sure there are others as well. All of these things are already pretty well solved by existing systems that don’t care a lot about where the content that is translated comes from. The translator’s choice of where to do the translating would be suitable in any of the plugins I tried before.
I think that in the short term this might be the most viable, albeit sub-optimal, solution to get value from the content being able to be read in other languages.