May 31st, 2002

  • dottey


I would like to take the Friends Edit page and have it split the list of users from a separate list of communities. In the top section it says "The following people have listed you as their friend..." Well, correct me if I'm wrong, but don't all communities you are joined in also list you as a friend? I guess having that information there is a bit redundant. But if should probably be there. I'd just like it in a list separate from the users.

The same thing goes for the bottom list which displays each friend of yours along with a Delete checkbox. It would be nice if the list was also separated into user and communities.

How do I go about doing this? Is it even possible? I guess I would like to know, and was having trouble finding, how do I get the "is this username a user or community?" returned? Is the hit this might take on the database worth it?

My answer is probably sitting in some documentation somewhere. I just haven't found it yet. Any help would be appreciated.

PS. I'm coming at this like I'd actually like to make the changes and create the patch. I'm not trying to make a suggestion - unless someone else knows exactly what to do and could write up the patch in 10 seconds :-p
amused, happy
  • mart

Translating the Client Protocol

Right now the server sends some stuff to clients on login which they are expected to just display. Now that there are non-English clients (such as the Russian version of Sema's client), I think it's about time the protocol learnt to deal with other languages too. To this end, I propose the following very simple solution.

Firstly, add a new hook into the translation system for the protocol messages. This includes the Web menu, and possibly other things I'm not thinking of. Since the Web menu is heirarchical, it seems logical to call the translation key things something like webmenu.recententries and webmenu.settings.personalinfo. This would be separate to the normal BML part, just like FAQs are, perhaps called something like 'clients' or somesuch. Alternatively, it could just use the same part BML does, if that's easier. It doesn't really matter incredibly if they're in a separate "namespace".

Now, I sat and pondered how clients should communicate their language with the server. One option was to use the Accept-Language HTTP header, which has the advantage of being standard and able to specify language preferences, but at the same time is probably overkill for what LJ needs. Instead, I think adding a protocol parameter clientlanguage would be a better idea, which takes only one standard ISO language code communicating what language the client's interface is in. This information does not infer anything else beyond that, and the server will only use it for selecting text which is intended to appear in the interface. For now, this can just be sent on login. If other protocol modes start to send languagish stuff in the future, the parameter can be added to those as well. I don't consider it harmful to add it later because old clients won't be aware of the new natural language data anyway, so they'll just ignore it rather than displaying it in the wrong language.

The server will look at this language code and use it to choose a language, and if that language is available the Web menu will be returned in that language and the client will display it as normal. I don't think it's really important to tell the client what language the Web menu is in, since the only acceptable course of action if the language doesn't match would be to display it in English anyway, and any untranslated strings will be returned in English even if the selected language exists.

One distinction I do think is worth making is between the different language settings that might be around in the future. This only deals with client interface language; that is, the language which the client's interface appears in to the user. Another kind of language setting which will become important soon is journal language, which is the primary language a user writes their journal in (with, of course, overrides for specific entries possible). These two don't necessarily need to match. The reason I brought up journal language is because I think the moodlist should be returned in the journal language rather than the client interface language, since users are more likely to write the mood in the language they wrote their entry in anyway.

So, this change is simple enough. Clients which don't send language will just get US English as they did before. Sema's Russian version will be able to get a web menu translated into Russian, and in the future other non-English versions of clients will be able to get menus which go with their interface too. If anyone sees any issue with this setup, please let me know.

Update: I forgot about the all-important error messages. These already have ID numbers associated with them so abstracting them out into the translation interface should be pretty easy, but of course this means that clientlanguage would need to be sent with every request.

  • dottey

Center tags question

Is there any reason, from a "browser compliance" or "specs" point of view, why there should be multiple center tags in code such as this:

<p align='center'>Random text</p>

If not, I'll probably remove the <center>s in the page I'm currently working on.
Eye of Thundera
  • dottey

[PATCH] for /friends/edit_do.bml

Per my question yesterday.

This patch modifies the two (HTML) tables (friends_of and friends) in edit_do.bml so that it lists users seperate from communities. This was never in suggestions but I thought of the idea and figured out how to implement it. Comment on it if you like this or not.

It has been tested by me so far and I think it looks good. You may test it on my goathack by going to the following URL and logging in as test/test

The patch is available here.
  • Current Mood
Morgan Webb 2

skip= paramater for customview.cgi

Can someone tell me what happened to this function of being able to use the 'skip=' feature with customview.cgi so that one can travel forwards/backwards for those that want to embed his/her journal into his/her own website.

Please refer to for more of a background.

As noted by macheide, this was a feature available at one time or another but no longer.

Thanks for your time.