Skip to main content
Topic: What's the recommended way to override just a couple of language strings? (Read 2721 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

What's the recommended way to override just a couple of language strings?

I think I only want to change $forum_copyright in index.english.php to add a couple of things and that's it. I assume the recommended way might be "create your own language" (assuming it pulls missing strings from the default), but in that case it doesn't help that the wiki is a stub. :P

Re: What's the recommended way to override just a couple of language strings?

Reply #1

The only language way that comes to mind is to make the changes in Addon.english.php ... you will have to globalize $forum_copyright; since its not quite a text string ....

Code: [Select]
global $forum_copyright;

$forum_copyright = 'What ever I need to say';
  Addon.english is the only one I can think of that allows the overwrite.

Other than that, you could use the integrate_buffer hook and manipulate the output string there.  A bit more work but thats how addons often add to that line as well as use the credits tag in the xml


Re: What's the recommended way to override just a couple of language strings?

Reply #2

Is it any different for normal language strings (i.e. without $1, $2, etc.)? That particular one is just my most pertinent example and the method I suggested is really not something I'm set on or anything. ;)

Edit: oh btw, which addons should I be looking at for examples, if you happen know any off the top of your head?

Re: What's the recommended way to override just a couple of language strings?

Reply #3

Should be no different for "normal" language strings, those are just $txt[''] = ''; stuff and you can use the same file. 

You could also edit the strings from the ACP if wanted, its no different then opening them up in vim and having at it. 

Addons.xxxx.php at allows an override (to index.english.php) as its loaded right after index.xxxx.php and you don't have to do anything, but if its some other string outside of index.english.php then that trick is not going to work.

Take a look at simple portal, it uses the integrate_buffer hook (see sources/PortalIntegration.subs.php => sp_integrate_buffer) for one way to manipulate that specific $forum_version line.

Re: What's the recommended way to override just a couple of language strings?

Reply #4

Quote from: Spuds – You could also edit the strings from the ACP if wanted, its no different then opening them up in vim and having at it.
Well sure, but I'm looking for the method that doesn't involve any work on my side while upgrading by being as forward compatible as possible. ;) That's why I suggested a custom "language" with a couple of overrides above, under the assumption that any missing strings would be taken from the default.

Regarding integrate_buffer, how's that performance-wise?

Re: What's the recommended way to override just a couple of language strings?

Reply #5

I'm responding to the "override" part of your question, you don't seem to be asking how to add a new string but to override an existing one.

To override you need to load your language file, custom or whatever, after the language file that contains the string you want to overwrite and before its used in the templates / sources.  The easy one is the index.english with addons.english  (and I mentioned that  in response to $forum_copyright).

If the string is not in index.english, but instead in one of the obscure language files, then I'm not sure TBH.  Its either find where its loaded and add use that controller hook, or maybe there is a hook in the loadlanguage controller that you could use and check if XYZ is being loaded then load your file to replace the strings.

Performance in integrate buffer should not be a concern, its just basic string search and replace that you are doing.  Its no more overhead then any other hook in the system.



Re: What's the recommended way to override just a couple of language strings?

Reply #6

Well, let me rephrase that "override" thing slightly; that may have been a badly chosen word. Does a language pack have to be complete or does it just fall back to some default? Because if that's not a feature, it should be taken into consideration. My potential use case ought to be pretty common (i.e., just a few forum-specific changes) but there's also stuff like formal and informal for many European languages other than English (vous/tu, jij/u, du/Sie). As such informal_french would specify to fall back to french (or maybe that'd be called formal_french) which in turn would fall back to the global default, English.

Anyway, I think integrate_buffer probably sounds like the way to go then. For my use case, if I were to add a new string I'd have to change the template anyway, which would kind of make the whole question moot. :)

Re: What's the recommended way to override just a couple of language strings?

Reply #7

Someone with a better understanding of how the language fallback works should  jump in here since I'm not sure on how that works.  Custom templates fall back to the system default, but I don't think language packs work like that.

If you create your own subset language, call it the Frenzie language,  it only has a few strings in some of the language files.
You make the default forum language French, but allow Frenzie to be user selectable. 
If it does not find the string in Frenzie, I don't think it falls back to check in the French pack instead, but who knows, maybe it does (and if not maybe it should)




Re: What's the recommended way to override just a couple of language strings?

Reply #8

Does Elk still support ThemeStrings.***.php? That allows overriding default language strings in SMF, so unless you've changed that code to nobble it the same should apply to Elk..
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: What's the recommended way to override just a couple of language strings?

Reply #9

Quote from: Spuds – Custom templates fall back to the system default,
Actually, I recently realized templates can fallback twice: the first time to a "parent" theme and then to default! :o
Anyway, that's another matter. :P

Languages: no, languages do not fallback twice, the only safety net is English.
There is an old discussion about a way to implement something similar to what you are describing: http://www.elkarte.net/community/index.php?topic=210.0

Re: What's the recommended way to override just a couple of language strings?

Reply #10

Quote from: Antechinus – Does Elk still support ThemeStrings.***.php? That allows overriding default language strings in SMF, so unless you've changed that code to nobble it the same should apply to Elk..
Ah, interesting. But could one have a "theme" of just ThemeStrings? :P

Quote from: emanuele – Actually, I recently realized templates can fallback twice: the first time to a "parent" theme and then to default! :o
Anyway, that's another matter. :P
That is, imo, how it should be, even if it wasn't intentionally implemented that way.

Regarding that discussion from three years ago, @Arantor said they wanted to implement pretty much exactly what I had in mind. Was that ever realized? :)

Re: What's the recommended way to override just a couple of language strings?

Reply #11

Quote from: Frenzie –
Quote from: Antechinus – Does Elk still support ThemeStrings.***.php? That allows overriding default language strings in SMF, so unless you've changed that code to nobble it the same should apply to Elk..
Ah, interesting. But could one have a "theme" of just ThemeStrings? :P

Quote from: Frenzie – I think I only want to change $forum_copyright in index.english.php to add a couple of things and that's it. I assume the recommended way might be "create your own language" (assuming it pulls missing strings from the default), but in that case it doesn't help that the wiki is a stub. :P
Your OP indicates that you just want to override a couple of default strings. Like I said, you can do that simply by adding a ThemeStrings.***.php file to whatever theme you are using. If you want to do something else, then your OP didn't indicate that.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: What's the recommended way to override just a couple of language strings?

Reply #12

Well, I decided to do a few more things with sp_integrate_buffer in lieu of forking a whole theme just for a few minor changes.

Anyway, ThemeStrings would only work for default strings because it's called prior to integrate_load_theme (which is quite useful still, of course). This means that every single add-on would need to integrate loadLanguage('ThemeStrings', '', false) after their own loadLanguage() calls for it to work in the manner I envision. It just doesn't sound like a complete solution, even if it might be adequate for the specific scenario I sketched in my OP. A language with fallback sounds like the Right Way™ (which is also how e.g. gettext works, because that's the logical way to work :P).

 

Re: What's the recommended way to override just a couple of language strings?

Reply #13

Quote from: Frenzie –
Quote from: emanuele – Actually, I recently realized templates can fallback twice: the first time to a "parent" theme and then to default! :o
Anyway, that's another matter. :P
That is, imo, how it should be, even if it wasn't intentionally implemented that way.
If you are referring to the themes, it was designed that way, it was just me that completely misunderstood it until recently.

Quote from: Frenzie – Regarding that discussion from three years ago, @Arantor said they wanted to implement pretty much exactly what I had in mind. Was that ever realized? :)
Judging by Wedge db-schema, they did.
About the idea, yes it is interesting. I'm not a fan either of editing the language files themselves to change strings[1], and not a big fan of storing them in so many places as well. But I would explore it.
Not that any change is "future proof", so even storing them in the db wouldn't remove the potential need to re-do the changes are an upgrade