How to handle site-specific content (e.g., text on home page)

[KeeperOfMaps]

Currently, site-specific content, such as the text on the home page, is stored in the template. To make it easier to maintain in the future, should we look at moving it into a config file and have it loaded by the page, as required?

I think this would make it easier to change the look-and-feel of the site in the future without having to worry as much about text.

Thoughts?

[TheRealFakeAdmin]

Not sure how I'd classify it, but Mailspring has a solution that could be useful or morphed for our needs. This adds the ability to have language settings in the future. [see here & here]

We can always drop the translation part and just have an ID system instead (ex: "main-page_title": "CSB 7.0").

[dpi209]

I don't want to sound too negative, but for me it wouldn't be done with swapping out some text with variables - i18n/l10n would require more work in regards of how we render pages. Also, text inherently needs to be project-specific, so we'd have to render out different sets of translation files and allow projects to localize their texts themselves.

So that'd be something for CSB 8.0 for me.

[KeeperOfMaps]

I agree. i18n/l10n should probably be the goal for CSB8.

It also isn't the sort of thing I was talking about. I am referring to text like left and right side bars on the home page. To make it maintainable for people who are not us, that text should be in either in an external config file or stored in the database like a content management system. The latter would mean we'd have to build an interface to manage it, but would make it easier for people to update it.

[dpi209]

You'd still need to make text variable for both.

[KeeperOfMaps]

True. The way that Mailspring seems to do it is by using the English text in the code as the key to an array/object that contains the translated version for the text. Then you pass it into a function that handles finding the appropriate language.

[dpi209]

You don't even have to look that terribly far - CSB app does it similarly, though much simpler (see csb-apps*\lang\en,json)
We could do it for English now but for the whole site. Main problem for me is the project level; we currently don't have storage there (only globally or in the apps, currently) so we'd likely have to think of a way to refactor string handling overall. And if we have to touch it anyway, we may as well implement it so that we can have different languages but keep working on default (=en)