jQuery Forum

When you access it for the first time (so that no 'lang' cookie exists) you will see the selector "All Parts..." in the top left control (the first item in "Search Control") and it displays the title='Select Part(s) to include in the search'. But if you switch the language to "русский" you will see that the whole widget is gone.

The entire JS code (and CSS) is embedded inside the index.html, so if you click on "View Page source" you will see the code in the function localise_site() at the very bottom of the file.

Maybe this has to do with the fact that this selector belongs to a control group (initialised via .controlgroup() method)?

UPDATE: I've found a workaround --- just do NOT use control groups at all! :)

The only disadvantage is that the widgets don't stick to each other, but there are other advantages --- e.g. buttons can be placed as I want them (i.e. both to the left and right of the input box) AND, more importantly, the checkbox doesn't disappear when one calls the .text() method on the label linked to it.

It's also best to do it on your server, rather than in the browser. To do it in the browser, you need to somehow incorporate strings for every language into the page - or perhaps make some Ajax request to request new strings. It doesn't make much sense to me to include every language in every page. Language change is (usually) a one-time affair for the user, and it shouldn't be very objectionable to wait for a new page to load. (I am assuming you would set some cookie so that additional pages would be sent in the desired language.)

But for this particular site my goal is to make it useable entirely without a server as well, i.e. via "file://" protocol locally. Unfortunately, cookies don't work with "file://" (neither in Chrome nor Firefox) so, some features will be missing. E.g. changing the language would work only for the current session and disappear after page re-load. If I implemented it the way you suggest (exactly as in the abovementioned library application), then language change would not work via "file://" at all.

Also, I need to think about carefully differentiating between embedded annotations (i.e. readonly part of the main book module) and user-defined (i.e. potentially shared) annotations --- I suppose for just this function I'll have to write some PHP code interacting with a database on the server and this function will be missing when used via "file://" protocol.

Boy, that's a lot of JS with hardcoded strings to switch languages! For every little bit of content (e.g. all those headings) there is some JS with a hardcoded string.

Hope it is only for 2 languages, not 15!

It's a fragile, bulky approach, that has no separate of concerns between content and code.

When I suggested using a SSG, I anticipated you might object to the increased size of duplicating the site per language. But now that I look at what you have, I believe that would result in less bulk than your current approach - because, currently, every bit of content carries around the dead weight of some Javascript that puts it in place on the page.

Which brings me to the following issue: the solution suggested by Jake above has one serious drawback: namely, the code associated with a widget (e.g. the .change() method for a selector) will have to be duplicated in three places:

1. Upon initial loading of the page (regardless of the localisation, i.e. with the content in English)

2. Upon switch to Russian

3. Upon switch to English

(and if we have 15 languages then it will be duplicated in 16 places). Ok, I can create a global function and simply call it from the selectmenu({change: ....}) template in 3 places, but even this is not very good, because, for example, one may add a new method and forget to update this fact in all the places where this selector is created.

So, is there really NO WAY to change the title attribute of a selector without destroying it? I would consider this a serious bug and will raise an issue. Where is the github page for jQuery UI? I can't seem to find it...

I also would like to ask: what is it that causes Chrome to display the old value of the title when Chrome's own "Inspect tool" shows the new value of title attribute when you point to the selector and right-click "Inspect"?

If you destroy it, the html for the "selectmenu" is removed. And when you recreate it, the <select> is read in with the new title.

You could go through the "new" HTML and change it, but that kind of poking around tends to break when there is a new release of UI. The only supported method is to destroy and recreate.

In that case, I will have to switch to the more traditional (and more familiar to me) way of doing the whole thing in PHP (plus jQuery for the UI), i.e. on the initial load check the "lang" cookie and then load the corresponding 'msg_???.php' file which contains the text strings for that language.

This means abandoning the idea of having the site useable via "file:///" protocol, but, I suppose I would have had to write the "server backend" for the shared annotations anyway, so now I won't have to write such a separate backend --- i.e. my entire php code will be "server backend" and will contain the user/group management as a small part of it.

The whole thing should still be useable locally (without Internet) but only by knowledgeable people who know how to configure Apache, MySQL and PHP locally on their laptop or desktop --- but obviously they would only be able to see and modify their own annotations, not others'.