Q: AAACK, all the text on my site/macro has turned to ***'s!
A: The ***'s are a symptom that the language strings for that page aren't loading properly. This could be a configuration error, a missing or corrupted strings file, or a syntax error in one of the macro files causing the strings file not to load.
To help debug this, your server writes a log called "logLangErrors.log" in the /system directory. In there, you'll see some lines like this:
Thu May 22 2003 02:02:15 GMT-0500 (CDT) - Missing string: tc - en_US - dateNames Thu May 22 2003 09:46:49 GMT-0500 (CDT) - Missing string: extn - en_US - btnnewburst
So in the first example, we need to make sure the English file containing the "tc" strings is present, and that the dateNames parameter is present in that file.
You can also check your webxIncludes.log (also in the /system directory) to see whether that file is actually being loaded by the server.
Also check to be sure that the file initing the entire language object hierarchy is present: webxLocal-init.tpl
Q: I copied macro foobar from webxStd-local.tpl, put it in webx.tpl
and customized it, and reset the cache. But now, all the text has
been replaced with ***'s.
A: You need to either provide a language strings file for your macro,
turn on "Enable 'std' strings" in the WCMS developer menu, or turn on
"Optimize for Localization" in your control panel > localization
The problem is that the strings for webxStd-local.tpl don't load
unless localization is turned on or the "Enable 'std' strings" option
Q: I customized some macros when 5.0 was in beta, and suddenly now when I upgraded all the strings have turned to ***'s!
A: Several "major" macros, including editPreferences and addDiscussion (the complete list is at the top of webxextn.tpl in the change notes), were moved from webxStd-local.tpl to webxextn.tpl for technical reasons shortly before 5.0 was released. If you've customized these macros, you'll have to do a search/replace on all your string calls in those macros to use the "extn" object.
So change: "lang".jsCall( "myString" ) or "lang( 'myString' )".jsEval to: "lang".jsCall( "extn", "myString" )
Q: Some places I see lang calls done like this: "lang( 'extn', 'myString' )".jsEval
and some places I see them done like this: "lang".jsCall( "extn", "myString" )
What's the difference?
A: Both will work; however, the jsEval syntax is older and slower. Whenever possible you should use the jsCall syntax in your macros because it's 5 to 6 times faster in retrieving the string, and considerably more forgiving of errors.
Q: The strings on my pages are missing, but there are no asterisks either.
A: This means that the main lang() function is missing - this function does the string replacements. This function is in the file webxLocal-lang.tpl. If this file is missing, you'll have to update your Base System plugin to get it back. (If your lang() calls are made with the jsEval syntax, you may have a large number of logJsError files as well, as a symptom of this.)
Q: I added a new language and set my preferences to the new language,
but I'm still seeing English buttons. How can I add localized
A: When you add a language, you also need to add localized buttons, otherwise the server now should return English buttons if the localized buttons are missing. If you aren't ready to make buttons yet, you can just copy over a set of English buttons into the new location. When you are ready to make buttons, we can supply a Macromedia Fireworks button template if you need one.
To add localized buttons, create a directory inside /Images with the name of the language code you created when you added the language. For example, if you're in Montreal, you may have added fr_CA (Canadian French). So create an /fr_CA directory inside /Images, and in there place the button directories for the buttons you're using on your site. If you're only using, say, /b17, you only need /b17 inside /fr_CA.
/Images/fr_CA/b17/ok.gif, for example.
Resynch if necessary, reset the file cache, and your buttons should return.
Q: On the "edit language strings" page in the localization manager, it says you can save language strings temporarily or permanently. What's the difference? Which one should I use?
A: Temporary saves only save the new strings temporarily in server RAM until the file cache is reset or the server is reset or restarted. This allows you to look at how your strings look in context without having to commit to them before you're happy. If you're the only one working on the server, and you're only doing translations, it's safe to use temporary saves while you're working. However, you may not be aware that a file cache reset is done in the background when plugins are installed, so your strings will be lost. Likewise, if anyone else is working on the server and might have the need to reset the cache, your strings will be lost. In that case, doing permanent saves is safer, because the strings are written to a file and will be reloaded when the cache is reset or the server is restarted or reset.