The language feature may be very interesting, but:
1. I think it will be difficult to get the language from browser info or based on the ip.
2. not everybody who uses hfs may use or understand more than one language, and even if they do, it's likely that guests with other languages connect to the site, and it would be useless to have lang-value for a language not supported.
Conclusion: In order to simplify the implementation of %lang% and it's use, I propose to make it user-selectable in the template with a method that somebody posted in this forum for other uses:
the method would be a link for each language supported by the site to the same page, adding a param.
example:
http://miserverip:port/?lang=itRejetto's work would be, where the logstring for requesterd gets is generated, to strip off what's coming after the '?' sign, check, if its 'lang' and put the value 'it' or whatever the href sends, into the %lang% variable asociated to the user, where the value remains during the session.
This involves to have bigger storage structure for each conected user, where until now there was only (I suppose, because I didn't view the source code..) a pair of values: username, userip.
By that way, I suggest also to add to more params like lang, that may be named 'upar1', 'upar2' and these values could be associated in the same way als ?lang=____. I want to use this params to select different styles, so that the user can select between different letter-size depending on it's screen, or to select fast-display-template with minimal graphic overhead instead of full presentation, depending on its conection (slow modem or LAN). Perhaps other users faind additional aplications for this.
If You go on working on that new user-structure, think also in adding a field for 'memberofgroups', that would be necessary to implement user-groups in the manner I will propose in a separate thread.
In a later future we could also think to leave these values in the user-account-management.