Language For Styles / CSS Loading

[EA117]

If you're going this way, I would do something like this:

That makes sense, but seemingly more from a perspective of "I'm going to still have just a single CSS file." Talk19Zehn didn't appear to explicitly specify where they were intending to store the CSS, so this is a good point to discuss regardless.

By Talk19Zehn's reference to the previous suggestion, I was expecting the intention was to leverage the language-specific CSS file like phpBB's prosilver already incorporates (./theme/en/stylesheet.css, ./theme/de/stylesheet.css, ./theme/fr/stylesheet.css, etc.).

Such that "translation contributions" are then the submission of additional language subdirectories for the style, versus having to edit in the additional language translations in-line within a central file. This was part of the attempt to mimic "best we can do" in absence of having an actual phpBB language directory supported in the style; where a common.php in a language-specific directory would provide additional style-specific language variables, and making "contributed" language submissions no different than how they're handled for extensions and phpBB itself.

Which would mean "keeping things simple" is that every language targets exactly the same class name, rather than a language-dependent class name. What will cause one language versus another to be displayed will be the fact that overall_header.html imported ./theme/de/stylesheet.css instead of ./theme/fr/stylesheet.css, etc.

The idea of language-specific class names is a great solution though, if the intention was to have only a single CSS style sheet defining all languages.


Edit: Ah, I see now Talk19Zehn's edit of their previous post, and now specifically stating that separate per-language CSS files are in fact being used. (artsmonode.css, versus artsmonoit.css, etc.) So separate CSS files instead of a single CSS file, but not using the ./theme/<lang>/stylesheet.css arrangement like prosilver had initiated.

[Dan Stylez]

In the end for the language thing, I made a simple extension called... Custom Style Language... It doesn't have any style files in... But it has a language file.

So in the HTML I add L_CSL_DATETIME which make the sidebar called Date & Time,

It may not be a recommended method but it's easier for me and makes it easier for the user to add their language to the extension instead of editing style files.

Basically the extension just adds a bunch of words to the phpBB that would be used in styles... bit like adding a dictionary extension to FireFox

[Gumboots]

By Talk19Zehn's reference to the previous suggestion, I was expecting the intention was to leverage the language-specific CSS file like phpBB's prosilver already incorporates (./theme/en/stylesheet.css, ./theme/de/stylesheet.css, ./theme/fr/stylesheet.css, etc.).

Such that "translation contributions" are then the submission of additional language subdirectories for the style, versus having to edit in the additional language translations in-line within a central file.

This would be a great way of handling it IMO. If anyone wanted to add an extra language, just copy the custom entries to an existing language file and change the translations to suit themselves. In fact it's such a good idea that I'm kicking myself that I didn't think of it first. It's the perfect way to get custom language strings into phpBB styles.

Although you could also have them all in one if you wanted to, but that's probably a less user-friendly approach for the average person. Particularly when you take the required custom template editing into account. Since phpBB gives you the standard theme/language directories and files anyway, IMO it makes sense to use them.

[Talk19Zehn]

The question was to additionally capture smaller approaches to language in a style, possibly via (css).
The actual CSS is already present in the stylesheet.css CSS is captured in English. Like the HTML in that style.
Thus, the CSS artsmonode.css, artsmonoit.css, etc. in the theme of the style directory and are included in the overall_header.html.

A readme.txt could enlighten the user, if this uses further (rarer) languages, in order to be able to use the HTML.

The question of an extension was, in my view, not the subject of the initial question. That there is this possibility, so was out of the question for me anyway in this topic.

[Gumboots]

The question was to additionally capture smaller approaches to language in a style, possibly via (css).
The actual CSS is already present in the stylesheet.css CSS is captured in English.

Sure, but the original CSS for any ::before or ::after content can be put into theme/en/stylesheet.css, like this:

Code: Select all

/* Online image */
.online { background-image: url("./icon_user_online.gif"); }
#some_element::after { content: "elephant"; }

Then if you want it in Czech you just grab theme/cz/stylesheet.css and add this to the end:

Code: Select all

#some_element::after { content: "slon"; }

Doesn't need any additional files or directories, and doesn't need template edits.

[Talk19Zehn]

That too is known. Does not clarify the question

...[...]...
First question... When creating an extension, you can add whatever language you want via the language folder... is there a similar way to add language to a style?
...[...]...

in style concepts to use language (CSS and/or languages (variables) that do not exist).

.

[Gumboots]

But you can add a language to a style just by using the files that already exist. I've just given an example. Now sure, you may not be able to do all the translations yourself, but anyone who wants to use them will be able to do it.

[Hanakin]

@Dan Stylez

2. The recommendation to use a custom.css file is meant for novice users and not style authors as its written there. However I still recommend overriding rather than changing to make things easier to upgrade. You do not need to have everything in one file and if you are making a custom style for release I would avoid this in your development repo. I would break all your changes up to be as modular as possible and then include/consolidate (scss imports not css imports as you want it to be merged physically for performance) them in to a single theme-name.css file that you include then via the stylesheet.css file at the bottom.

This makes it extremely easier to maintain going forward across releases. Since you can use the posted changes to check all your edits based on selector.

3. I personally hate that page, it points out what they call "advantages" but it really needs reworked as none of it is really 100% accurate. Going forward with 4.0 that page will get an overhaul as the inheritance system will be changed. I would recommend sticking with using the current method of editing just the css files. Modifying the overall header adds an additional layer of complexity that is not necessary for no real significant advantage anymore. It was all based on old browsers and old protocols which have all been vastly updated.