Jump to content

DOMiD Labs – Microsite for a museum-related project


schwarzdesign
 Share

Recommended Posts

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.

domidlabs-homepage.thumb.png.4aed50b20820b754e3c3c808d67cde17.png

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 (not yet online).
  • Multi-language support (English site yet to follow).
  • 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

  • Like 12
Link to comment
Share on other sites

  • 2 weeks later...

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?

Link to comment
Share on other sites

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 ^^

  • Like 1
Link to comment
Share on other sites

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()

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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!

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...