Skip to main content ↑ ↓
Topic: Javascript text strings (Read 7254 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Javascript text strings

While adding "more and more" ajax/javascript things, we will have an increasing need to use localised strings in javascript, for the moment we are "throwing" them somehow at random into variables loaded around in the scripts, it may be worth starting consider some "long-term" solution to avoid conflicts, duplicates, and so on.

I'm not sure what's the "best" practice.
Bugs creator.
Features destroyer.
Template killer.

Re: Javascript text strings

Reply #1 –

The Wedge way is overkill right now for Elk. But since I've been caching and optimizing CSS and js for years now, Wess is very flexible when it comes to that and it rocks. Something to consider in the future I suppose. Of course, you'll have to maintain a cached js file per file per language.

Re: Javascript text strings

Reply #2 –

Especially since you have a cache/optimize solution now, use a Javascript language file. If it becomes too big (>100KB I would say), split it up.

Re: Javascript text strings

Reply #3 –

I considered doing that when I first implemented the feature, but it was just as quick to add strings directly where they were needed. And less of a bandwidth waste, but I've already made my point about JS files getting too big, I think... ;)
How about JS files that are not loaded often (e.g. admin files), you still have to load their strings in this case..? Even Google would get to load them.

Re: Javascript text strings

Reply #4 –

How about putting all strings at once on a global object?

Code: [Select]
var langStrings = '. json_encode($txt). ';

Don't worry about the json_encode, I've already included the fallback function.

Re: Javascript text strings

Reply #5 –

Since the editor translation was broken anyway, I started here to take care of that:
https://github.com/emanuele45/Dialogo/commit/c6cec940e42641d155dfbc4ec35493f98b18acf3
I added a new controller that could be used for this kind of things (i.e. generate different js files), it's still not nice to read, but for 1.0 should work.
Bugs creator.
Features destroyer.
Template killer.

Javascript localization

Reply #6 –

The more we use javascript, the more ugly arrays, objects or bunches of random variables are sent out to the client via the php files.
To me this doesn't seem very organized.

Honestly I'm not sure what's the best here, so I'm posting to hear if you have any experience and/or any idea.

At the moment, the only kind-of-organized thing we do, is have an action that builds a js file for the localization of the editor.
It's nice, but it doesn't feel "good" either (at least to me).

One possibility I was thinking about, is use one or more javascript/json/txt/whatever files that would be requested by the client.
Of course it's not a perfect solution either: it would potentially mean duplication of some strings[1] and it may not allow "easy" adding of strings (I mean by mods). If it is one file, it also would mean the client has to download it and load it in memory (and I mean that for each page you'd have a file with potentially tons of unused strings just because you need one[2]. On the other hand, multiple files would mean more requests.
Another possibility would be to keep the language strings in php and have an action that generates the strings[3], at the price of parsing more stuff through php at each page load[4].

Soo.... Comments? Opinions? Ideas? Previous experiences that may help?
1 Between php and javascript, but I have no idea how many↵
2 Of course this is kind of hypothetical because I have no idea at the moment of how many strings we are talking about.↵
3 This would give more flexibility and (potentially) make easier to add new strings↵
4 Not entirely true, especially if the minification is on.↵
Bugs creator.
Features destroyer.
Template killer.

Re: Javascript localization

Reply #7 –

Umm what if the JS on the page doesn't need any text string?

How about having a PHP function in which only text keys are passed via array or something from the source file, it grabs those values from text files and on page onload those strings are passed to JS under a predefined object name. So it'd be easy to track what lang strings are used by JS from the specified source file. Just a thought :P

Maintaining 2 completely separate files seems to be a trouble in the longer run.

Re: Javascript localization

Reply #8 –

I think two or three files would cover everything from regular user, moderator, and administrator. You could even combine moderator and administrator because they'll probably overlap.

Re: Javascript text strings

Reply #9 –

I forgot I already started a similar topic a while ago... Merged. ;D

@Joker™ I think there may be problems, at least it's not that flexible, for example, you may write an addon "js-only", it's possible, but if we "force" localization through php, it will require at least one php file to hook into the system.
Looking at the commit linked above, I realized I already took that path: the jslocale allows to generate a javascript file based on a certain array of strings, the current limitation is that (obviously) it is (still) not easy to extend: it follows naming pattern, but we don't have an "automatic" pattern for subactions (we have only the hooking in the Action class), so it needs a better approach.

An option may be tu use the sub-action to identify the language file we want to load (e.g. sa=myadd => Myadd.{language}.php), the variables needed (e.g. sa=myadd => $txtmyadd) and generate the code based on that.
It is still bound to jquery and its extension system ($.{pluginname}.locale[something]), so it may need some work...
Bugs creator.
Features destroyer.
Template killer.

Re: Javascript text strings

Reply #10 –

I think the first thing to do is compile all of the strings in a single Javascript file. Then break it apart based on what is needed. I think dozens of files is going to be a huge pain to maintain (rhymes hehe).