#1
Any tips or ideas about how to have a language string resource file, and to make it accessible? I don't know if I should make a module that loads the php file with an array in it. My plan is to have it be able to load different languages. A module or a helper file and make a short function not part of a class like `_l()` or just a global array and use `$lang['create project']`?

Having a function like _l() that uses a global variable where somehow i load the proper language by intercepting and parsing the `/$lang/module/function/$data` to get the language and loading the proper php file with the array in it.
#2

The thread creator has indicated that this post solved the problem or provided the best insight.

Members who post winning responses earn points for our leaderboard.
Points mean prizes!
The simplest approach in v2 is to load a language array early in the request cycle using an interceptor, store it in a global variable, and then access strings throughout the app via a small helper function like _l(), keeping language resolution separate from how the strings are actually used in views and controllers.

** Edit
Here is an implementation of a language module I created for this post:

Add this to `config/config.php`:


Add this to `config/custom_routes.php`:
Note: add more segments if needed


README.md

The controller > `language/Language.php`:


The helper `language/language_helper.php`:


Enjoy!

Si
#3
That's brilliant. You should do a video tutorial.
#4
Still needed some work... I have now updated the previous post with a better version of the controller. All is now working as expected. Not sure about a video tutorial, but I'll create a repo for it soon.
#5
This is great, thank you.

My first knee-jerk reaction is that the interceptor should be called init (or inter) rather than before, but that's just me.

I had designed something simpler, and I see this sidesteps some of the security issues I was concerned about. Great!

I see you had to grab the raw URL data. I got in to trouble because I read that intercepts are before routes, and thought that meant before the custom routing rules are applied. I'd recommend adding a side note to the documentation that it's after that and segments will show the result of the custom routing.

Also, the document references the defunct module market. So that reference should probably be removed.
#6
I figured I'd show some code I was playing with. You see here it uses the url_title() to strip special characters out of the lang name. And I made mine so it would work with just one language using the override feature which prevents it from looking anything up.

A key feature is that there is a missing string warning. (In theory, you could have that only run in dev and not prod, but I don't like silent fallbacks.)

But I will use what you've made so far. Let me know the repo so can get any updates you make for before I start my projects.

#7
You can also have it set to just ignore the language without setting each language code in the files. So rather than `en/(:any)/(:any)`. Just ignore it. I had to be way more specific, so my routes are longer for what I need. But I just ignore $1, as such:



This is working great with your code.
#8
No worries, glad it’s working out for you!

Yeah, I agree - the naming of the interceptor could have been better thought out. `before` hook seemed logical at the time.

I didn’t dig into the docs for interceptors; I just jumped into ignition.php, followed its logic, and got stuck in. I had to grab the raw URI because the custom routes already stripped segment(1), and I needed the language ID from the URL. Good point about the docs - maybe DC will update that soon.

Thanks for sharing your code as well - really good work there!

I’ve pushed the module to GitHub: https://github.com/DaFa66/t2_lang

And here’s a quick demo video that DC requested (yeah, I know my demo skills need work—definitely leave tutorials to DC 😅). >> https://youtu.be/qF3poNj6C54

Cheers,
Simon
#9
What an impressive job you did with the language module, Simon! Thank you for sharing the GitHub link and the video walkthrough. They are incredibly helpful. I think you could produce some absolutely amazing tutorials for Trongate v2!
#10
I was playing around with the language module you made and discovered something. As I mentioned before, you can change the custom routing to accept any lang and not have to hard code them yourself, such as:



But you can be more generic than that, as DaFa showed with his `'en/(:any)/(:any)'=>'$1/$2'`. So I thought I'd combine them where we ignore the languge `$1` segment:



And this technically works fine, but with '(:any)/(:any)/(:any)' it executes before realizing `welcome_module/css/custom.css` should activate the MODULE_ASSETS_TRIGGER and instead I get a 404.

Two things:

First, I feel like in the routing and the intercept, the order of execution should be outlined. In interceptors, the intercept is before the routing is executing, but after custom routing is applied. And in custom routing that the MODULE_ASSETS_TRIGGER is applied after the custom routing changes the segments. This sequence of execution isn't mentioned anywhere as far as I know.

Second, I feel that the MODULE_ASSETS_TRIGGER should override everything by being applied to the raw URL or being executed before custom routing rules are applied. I think it should happen before routing, before intercepts and before custom routing because that would be the fastest.

However, this would mean you couldn't log requests to assets if it is applied before the interceptor. Is that useful? It may also add complexity to the engine that is not worth it.

Finally, for those following along and for completeness, so long as you are very specific, like including module names or something, this effect is side stepped. Like:



You won't run in to this problem. I will have to think out my exact URL structure, because I was hoping for (:any)/(:any) lang/project, so I have to be sure I'm specific with the method names.

This can be sidestepped by just hard-coding the lang codes, as you did originally, DaFa.

Thanks for your work.