Some language strings contain square brackets to border the text, for example:
datahandler_pm.lang.php: $l['pmdata_code_no_subject'] = '
[no subject]';
global.lang.php: $l['view_attachments'] = '
[View My Attachments]';
private.lang.php: $l['deny_receipt'] = '
[Deny Receipt]';
These fixed brackets could make a theme designing more inflexible.
Any additional text decoration (brackes and similar) in language strings should better be outsourced to templates, like:
private.lang.php: $l['deny_receipt'] = 'Deny Receipt';
Template "private_messagebit_denyreceipt":
[<a href="private.php?action=read&pmid={$message['pmid']}&denyreceipt=1">{$lang->deny_receipt}</a>
]
[ExiTuS]
Would the square brackets depend on the language? Would we need to introduce two new language variables (one for opening and one for closing) for this semantic?
No...
it's just about these brackets as part of a string.
A bracket character is kind of "text decoration" and should not be part of a language string.
This is still an open suggestion.
[ETS]
Since this is in language strings which is easily editable by admin what is the point of imposing a change?
The same thing applies to colons also, sometimes they are completely unnecessary; but still there in the language strings.
I will side with
["ExiTuS"] in this matter.
It is clear the brackets are intended to highlight a CTA (call to action) or to emphasize something.
(2024-04-19, 09:39 PM)effone Wrote: [ -> ]Since this is in language strings which is easily editable by admin what is the point of imposing a change?
This motivates theme designers to simply hard code new language strings instead.
(2024-04-19, 09:39 PM)effone Wrote: [ -> ]The same thing applies to colons also, sometimes they are completely unnecessary; but still there in the language strings.
I suppose this is an instance where the ones deciding are the coders; instead of the designers.
(2024-04-19, 09:39 PM)effone Wrote: [ -> ]The same thing applies to colons also, sometimes they are completely unnecessary; but still there in the language strings.
In this case you should not equate punctuation with special text decoration.
But you're right at all - so next suggestion:
Check for completely unnecessary colons and remove
[ETS]
Well, I must not deny the necessity of the idea from the designer point of view!
Sometimes those unnecessary characters are really irritating and those should be transferred to templates...
But again, from admins perspective - its simply fine wherever it is unless its hardcoded.
These are indeed outside of the language semantics (like HTML). Moving them from language strings to templates in 1.9 won't cause any issues, so feel free to open a PR on the branch and we'll have it merged.