DOMiD Labs – Microsite for a museum-related project

[schwarzdesign]

We recently launched DOMiD Labs, a new microsite for our existing client DOMiD. We already built the main site for DOMiD in 2019, as shown in our previous post here and featured in ProcessWire Weekly #296. The new DOMiD Labs site belongs to a project to plan participative museum concepts for the upcoming migration museum in Cologne, Germany.

Concept, design and implementation by schwarzdesign - web agency in Cologne, Germany.

Featured in ProcessWire Weekly #433

We're using an in-house starter project to bootstrap new ProcessWire projects. This allows us to deliver smaller projects on a low budget while still providing an extensive, modular content system and to spend some time polishing the features our clients care about. Notable features of the site include:

• A modular content builder utilizing the excellent Repeater Matrix field.
• A blog area with a paginated news index page.
• Multi-language support (site available in English and German).
• Q&A sections using accordion elements.
• A contact form built with the Form Builder module.
• Fully configurable navigation and footer components.
• Custom translation management for interface translations.

Learn more: domidlabs.de

[bernhard]

Beautiful site as always ? 

On 6/1/2022 at 4:30 PM, schwarzdesign said:

Custom translation management for interface translations.

Do you have some details on that one?

[MoritzLost]

On 6/14/2022 at 9:53 PM, bernhard said:

Beautiful site as always ? 

Do you have some details on that one?

@bernhard Thanks! We can't use the built-in translation system because it can't detect translations in Twig templates, and because the interface is a bit too technical for our average client. So we rolled our own translation system, which is built on a single ProFields Table field located on the global settings page. Doesn't scale super well and doesn't include stuff like pluralization, context translations and parameter replacements, but does the job for simple interface translations on small to medium sites. It's basically the approach outlined in my custom functionality section in my ProcessWire + Twig tutorial. Though it went through a couple of changes since then, most notably I optimized the way the table field is loaded. The current version loads all rows for each call to the translation function, which was terrible for performance. Gotta remember to update that in the tutorial at some point ^^

[bernhard]

Hi @MoritzLost that's interesting! I've recently fallen in love with latte and there I have the same issue. I didn't think of that until know as I've not been using it on a multilang site yet. Your approach with the table field is interesting, especially the fact that it creates rows automatically from code and populates a default value. Though I'm not sure if I really like that approach or not. I think if the default value is changed by the client and a developer looks into the code and tries to change the wording there this might lead to unexpected results as that change would not have any effect since the new value will not be written to the translations? On the other hand having the msgid has the benefit that if you change the wording in the initial language you don't lose the relation to the translation which would be the case in PW's internal system... There's always a pro and con ? 

Anyway.. it's not really a big issue for me since I'm always using custom page classes and I can easily add a method there that returns a translatable label, eg $page->buttonLabel()

[MoritzLost]

17 hours ago, bernhard said:

I think if the default value is changed by the client and a developer looks into the code and tries to change the wording there this might lead to unexpected results as that change would not have any effect since the new value will not be written to the translations?

@bernhard Including the default translations in the code has also fallen a bit out of favour for me, for that exact reason. Since we're using snake-case message IDs (e.g. contact_form_submit_label instead of Submit), it's nice to see the actual translation directly in the code alongside the ID. But if those get changed in the table field, it gets confusing indeed. Usually the message IDs are enough to understand what the message is intended for (and if not, this can be solved by writing better message IDs). Lately I don't include the default translations in the code as it's just as easy to add them in the table field after. I still like that the empty row with the message ID is created whenever a new translation is added, this makes it easy to add a bunch of translatable strings in the code and add the translations later in bulk.

17 hours ago, bernhard said:

On the other hand having the msgid has the benefit that if you change the wording in the initial language you don't lose the relation to the translation which would be the case in PW's internal system... There's always a pro and con ? 

Absolutely, this is why I always prefer message IDs over writing translations directly in a fixed source language. This has the nice benefit that you can differentiate between contexts using the message ID - for example, contact_form_submit_label is different from order_form_submit_label. This means you don't have to built context awareness into your custom translation system, making it much easier to implement.

[zoeck]

On 6/17/2022 at 7:29 PM, bernhard said:

I've recently fallen in love with latte and there I have the same issue.

Can you shortly explain how you use latte in PW?
Do you use the "Template Engine Factory" module for this?
Latte sounds very interesting!

[bernhard]

34 minutes ago, zoeck said:

Can you shortly explain how you use latte in PW?
Do you use the "Template Engine Factory" module for this?
Latte sounds very interesting!

Sure ? 

<html>
  <head>
    <?php
    echo $rockfrontend->scripts('head')
      ->add('/wire/modules/AdminTheme/AdminThemeUikit/uikit/dist/js/uikit.min.js')
      ->add('//unpkg.com/alpinejs', 'defer')
      ->addIf('/path/to/debug.js', $config->debug)
      ->render();
    echo $rockfrontend->styles('head')
      ->add('/wire/modules/AdminTheme/AdminThemeUikit/uikit/src/less/uikit.theme.less')
      // add all styles (CSS/LESS) inside /site/template/sections
      ->addAll('sections')
      ->render();
    ?>
  </head>
  <body>
    <?= $rockfrontend->render("sections/header.latte") ?>
    <?= $rockfrontend->render("sections/main.latte") ?>
    <?= $rockfrontend->render("sections/footer.latte") ?>
  </body>
</html>

I've used that module (RockFrontend) for several projects now and I'll release it soon. If you or anybody else wants to try it out and give me some feedback write me a PM!

[schwarzdesign]

Thanks for featuring this site in ProcessWire Weekly #443!

Small update, the English site and the news section have been finished and are online now. If you're interested in the migration history and the museum, you can check out the English site!