Best Practices for Multi-Country, Multi-Language Site Architecture in SPIP 4.x (Content Organization & Template Variants)

Général
1

Dear SPIP Community/Developers,

I am developing a website for a global diaspora using SPIP 4.x. The site aims to serve a community distributed across multiple countries (e.g., Germany, Norway, etc.) and in multiple languages (e.g., German, Norwegian, Hazaragi, English), with each country’s content and sections also needing to be available in multiple languages.

A core challenge I’m facing is determining the most logical and scalable site structure for organizing content and delivering localized experiences using template variants (object-ID.lang.html, object.lang.html). I am aware of SPIP Multisite functionality, but due to concerns regarding heavy backup processes and the complexities of distributed admin tasks and control, I am concentrating on a single instance installation for this project.

My Current Setup Context: I have my absolute site homepage served by sommaire.html and its language variants (e.g., sommaire.haz.html).

Here are the structural scenarios I’m considering:

Scenario 1: Grouping by Geography/Audience

  • Structure: Content is primarily organized by top-level country sections, with sub-sections for content types within each country.
    • Site Root (sommaire.html)
      • Country A (Section ID 1)
        • Events (Section ID 3)
        • News (Section ID 4)
      • Country B (Section ID 2)
        • Events (Section ID 5)
        • News (Section ID 6)
  • Template Logic:
    • Country homepages: rubrique-1.de.html, rubrique-1.haz.html, etc.
    • Country-specific sub-sections: rubrique-3.de.html, rubrique-3.haz.html, etc.
    • Articles: article-1.de.html (for German articles within Country A’s branch), article-2.no.html (for Norwegian articles within Country B’s branch), etc.
  • Pros (as I see them): Intuitive for users identifying by location, clear content segregation.
  • Cons (as I see them): Harder to get global overviews (e.g., « all news »), potential for content duplication if an item is relevant to multiple countries, potentially less scalable for many countries.

Scenario 2: No Dedicated « Country Homepage » - Rely on Global Homepage and Filtering (Pure Content-Type First)

  • Structure: Content is primarily organized by type across the entire site. Country-specific content is accessed by filtering on these content-type pages using keywords/tags.
    • Site Root (sommaire.html)
      • News (Section ID 1)
      • Articles (Section ID 2)
      • Events (Section ID 3)
      • Integration (Section ID 4)
      • Future (Section ID 5)
  • Template Logic:
    • Section homepages for content types: rubrique-1.de.html (for German version of the News section), rubrique-3.haz.html (for Hazaragi version of Events section), etc.
    • Articles: article-1.de.html (for German articles within the News section), article-3.no.html (for Norwegian articles within the Events section), etc.
    • Country Specificity: Managed through SPIP mots-clés (keywords) like « Country A, » « Country B, » assigned to articles, which are then filtered for in the templates.
  • Pros: Content-centric, global overviews are easy, highly scalable for adding new countries.
  • Cons: No single « country homepage, » heavy reliance on consistent keyword tagging, filtering logic needed in templates might be complex for beginners.

Scenario 3: Hybrid Approach - Create « Country Portal » Sections

  • Structure: Combines content-type organization with dedicated « portal » sections for each country, which aggregate content from the content-type sections. For instance, the first section IDs could be reserved for country portals, followed by sections for content types.
    • Site Root (sommaire.html)
      • Country A Portal (Section ID 1)
      • Country B Portal (Section ID 2)
      • News (Section ID 3)
      • Articles (Section ID 4)
      • Events (Section ID 5)
      • Integration (Section ID 6)
      • Future (Section ID 7)
  • Template Logic:
    • Content-type sections use rubrique-CONTENT_TYPE_ID.lang.html (as in Scenario 2, e.g., rubrique-3.de.html for News).
    • Country Portal Homepages: rubrique-1.de.html (German homepage for Country A Portal), rubrique-2.haz.html (Hazaragi homepage for Country B Portal), etc.
    • These Country Portal templates use SPIP loops with id_rubrique and titre_mot criteria to pull and display relevant content from the central content-type sections (e.g., all articles tagged « Country A » from the « News » section).
  • Pros: Dedicated country entry points for geographically-minded users, while keeping content organized by type in the backend. Offers good balance and flexibility.
  • Cons: Adds more sections in the backend hierarchy, aggregation loops in portal templates can be more complex.

My Questions to the Developers:

  1. From a SPIP best practices perspective, which of these three scenarios (or a variation thereof) do you generally recommend for a complex multi-country, multi-language site aiming to serve a global diaspora with regional interests?
  2. Are there any known pitfalls or specific SPIP features/plugins (beyond squelettes par rubriques and champs extras) that would significantly improve the implementation of each scenario?
  3. For Scenario 2 (pure content-type first), how would you best implement intuitive « country-specific views » within the main content-type pages (e.g., a tabbed interface, dropdown filter, etc.) to ensure content discoverability without creating separate sections?
  4. Is there a fourth, fundamentally different and better architectural approach in SPIP that I haven’t considered, which is more robust or easier to maintain for this type of site?

Any guidance, examples, or pointers to relevant documentation would be immensely helpful in ensuring a stable and maintainable SPIP site.

Thank you for your time and expertise!

2

Hi,

I currently host a personal blog in 3 languages where I’ve chosen an architecture tree that is a strict mirror for all the languages, with a root section for each language.

My articles and sections have cross-language links which allow users that would arrive for whatever reason on the wrong language, to move to the right language.

When I create a new section or a new article, I mirror it in the 3 languages before putting them officially online.

I have used three plug-ins to help me:

And Spip also has a general tutorial about setting up a multi-language website here: Creating a multilingual site - SPIP

But from what I understand, I don’t think your portal matches my (basic) scenario, it more looks like several independent trees that will evolve independently of each other. And from time to time you need to post something in all the trees at once.

The question is how often is this « from time to time » and if this is really a thing or not (because your trees are in a different languages, I’m not sure how displaying an article in language A, in tree of language B, would/should look like)?

2 « J'aime »
3

Hi,

Take a look at AutoLang : Aiguiller le visiteur selon sa langue de navigateur - SPIP-Contrib

And also :

You might also try Squelette SoyezCréateurs Rebirth - Plugins SPIP

You might also have to do translations with : https://trad.spip.net/ (for plugins that would not have the translations you need).

1 « J'aime »
4

@spipfollower There is no one better approach, and moreover, it’s not a good idea to start from technical. Almost all is possible in terms of architecture and technique, but it would be better to start from UX: what would be better for final users? what navigation, what division of categories, etc.

Also: are the pages really need to be fundamentaly different between languages? or they will be just slightly different? and what kind of differences? All those questions are important to determinate the better final architecture.

For exemple, if the content or presentation will be only slightly different, it’s not a good idea to make a different template for each language for each page… It’s really better to share the same code, and add little tests on current language here and there if necessary and display different things in those tests. Making templates by language code must be the very last solution (sometimes we need but super rarely).

Conversely, if there will be more heavy differences BUT if those differences are « generalizable » and could be use for this or there language, then… it’s better to design multiple « compositions » (with the plugin) and apply the right one to each major sectors.

3 « J'aime »