You need to have subdomain s for that. Do not try to use the translation plugins, It is only a way to make things harder.
That said as a translator.
I don’t know what the best approach might be, but what I do know we don’t have resources to manage multiple instances of CP on subdomains. We have to figure out a way to do it with one instance, be it a plugin, multisite, or custom solution.
Whatever we do, it will be a good case study for building multi-lingual websites using CP.
1 Like
Multisite is the way to go. No need to translate everything at the same time and also allows specific content for specific countries.
Also, a good way to prove the power of CP Multisite.
2 Likes
See https://multilingualpress.org/ and Multisite Language Switcher – WordPress plugin | WordPress.org
1 Like
I have a clound hosting with the following features:
Server configuration:
Input Processes: 60
Physical Memory: 32 GB
IOPS: 1,024,000
I / O Usage: 20MB / s
Number Of Processes: 400
It has a simple cPanel, so very easy to manage and configure.
I pay and use it right now for classicpress.it. If you want we can do the multisite above and I’ll take care of the shopping and we already combine the Italian version.
If it’s not out of place to use Beaver Builder, I believe that in a couple of days I could do it all by transferring the content.
I am also available now if you want.
I said multisite before, but another idea is to actually have multiple sites, as in multiple CP installations in different servers handled by different people (trusted by the community, and at least two or three who work together, not only one).
This will help to decentralize the project (and share the work load).
OF COURSE, all the sites, be it Italian, German or Gaelic, shall respect common guidelines about values, branding, no ads…
Not respecting those guidelines will result in the site being considered non-official.
With a little bit of respect and maturity, this shall not be an issue.
Decentralizing the project is important, especially with what is going on now.
1 Like
This is what I was saying above. Every install has translators.
Basically the matrix of the site is static. They would only need to translate every post that gets published once all the static parts are translated.
So being that the blog won’t be a flood of content they can stay on top of it with ease.
That is why I recommend not using plugins that include all translations in custom fields for every post.
This is a recipe for disaster. Open source is riddled with examples of how once “good” contributors can go “rogue”. We have some minor examples in this community, too.
Decentralizing access is good, but we can’t just label it “unofficial” if something happens. We need to be able to takeover if something goes wrong. It’s not just bad PR, but can do real damage to the project or worse, to the end-users.
Examples:
3 Likes
Any person with access can get mad. That’s why decentralization matters. So that one or two people cannot get mad and make everyone else pay for it… and ironically… that’s what happened in both examples you provided?
Decentralized stuff is protected against this. At least not the whole thing breaks if a part does.
Do directors need to be more trusted than trusted community collaborators? So they can control everything and break everything if they want to?
A community shall vote trusted people and let them take their role.
It’s the opposite what is a recipe for disaster, as we are more or less seeing with the current state of CP.
Technically yes, directors are legally obligated to manage non-profit. But that’s also why community needs to have a say in what directors do and replace directors if necessary.
Been there, done that. We had an elected board/committee in the early days. If you search the forums, you’ll find voting and candidate profiles, etc. It didn’t work out. This is why it’s important to know what has been tried and didn’t work, so we don’t repeat the history. We didn’t get here overnight. There are 4 years of trial and error. We can’t ignore it, on otherwise we will repeat it.
But we’re getting off topic.
1 Like
These seem like good choices for the main site
1 Like
I would like to see someone evaluate what the best way to proceed here is, so that we can get to work on it. It involves a different area of expertise from developing the CP software, so it’s an opportunity for different people to be directly involved. It’s also an opportunity for the new Directors of the CPI to work with the community in resolving an infrastructure question and then putting the appropriate things in place.
It seems to me that the fundamental issue here is whether it’s better to handle internationalization of the main site via multisite or via subdomains of subdirectories. There seem to be several issues to consider here:
-
Relative ease of use and maintenance. @williampatton may have thoughts on that.
-
Whether it’s a good idea to use one or several databases. Multisite uses one, and I remember Mika Epstein saying that works best if you are going to be having users visit more than one site. That doesn’t seem likely here, so maybe it would be better to have multiple databases and therefore use subdirectories or subdomains.
-
What software (including plugins) we will need to use for internationalization. Presumably some options work better with multisite and others better with single sites. Someone needs to evaluate these options.
I don’t have the expertise to carry out these evaluations. But if someone (or, ideally, several people) could do so and discuss their thoughts here, then the CPI Directors can get on with the job of creating/modifying the relevant sites and providing appropriate access to the appropriate people.
This is a bit incorrect. Multisite uses one copy of the software, but multiple folders for media and each subsite has its own database.
Edit: Sorry, not each site has its own database, but each has its own tables in one database, so yes, it’s one database.
I though all subsites are in the same database and have a site identifier in the table names?
1 Like
I haven’t used multisite in a minute, but I remember it used one database but multiple tables prefixed with site IDs. But one set of db credentials, just like single site. Did that change?
1 Like
Sorry for the misinformation… I hadn’t looked at it for awhile either.
2 Likes
One thing I want to add to multisite vs single site, using single site per language adds to maintenance work to maintain each site.
I would go with multisite to reduce maintenance work, while translators would have access to manage content.
I started using multisite a few years ago for this reason, but when I moved web host I separated the sites out as I’d been having some issues and decided that the separate sites would be easier overall.
Perhaps this was merely down to my learning about mutlisite at the time and not knowing enough to use it efficiently.
There are things that’s easier to do in single site compared to multisite, but if websites use identical theme and plugins, while content is the only thing that changes then multisite is a good option.
1 Like
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