Completed French translation

Yes, that's why I documented the /qqq help text, saying that this was a bug/limitation of Translatewiki which does not accept the ampersand. see also my message above : the resource name is NOT corectly encapsulated in the HTTP GET URL (it should have been URL encoded on submission, and the TranslateWiki.net server does not validate all its parameters when it sees an ampersand separator followed by a string that does not contain an equal sign). This should be reported as a bug of Translatewiki.net's AJAX code (a better fix should really use POST requests when submitting translations or reading them). Anyway, I really suggest that you avoid ampersands in your MIFOS sources for resource names (just like you already drop espaces and some other "unsafe" characters like equal signs or newlines).

Having the message name and other important bits in the url is really useful for debugging. Using POST would not be semantically correct, since it doesn't change state in the server.

Really I don't understand your argument. A POST necessarily changes the state on the server of the target resource (this is the default behavior for HTTP). The server reports the change to clients that are querying it by HTTP "STAT" requests, and any POST request is (by default) not cachable by all conforming proxies (unless your HTTP request specifies it explicitly).

But loading the dialog doesn't change state in the server. Saving does, but that is already POST.

This is an issue of Loading the dialog which still does not perform STAT requests to validate what is currently cached in Javascript variables. In fact this is very irritating : opening any question by clicking it should always revalidate its preloaded and cached resources, but it still displays old values that have already been updated by someone else or in a separate window (for example in a search window when checking the terminology used in other "similar" resources).

This revalidation should be done to help reviewing the existing translations, including those that we have done ourself (and that disappear from the list of "untranslated messages" if we refresh the window to void the local Javascript cache variables (usd by the AJAX editor to open movable dialogs in the current window). For now the best that can be done is to force all clicks to open a new window or tab, to avoid loosing the current list.

Anyway, this is not an issue of MIFOS itself but a usability issue of TranslateWiki.