GwynethLlewelyn
commented
3 years ago Hi! I'm not one of the project developers, but I was aware that Gallery used to be very good at supporting a plethora of languages, and it was quite easy to add new ones (or correct existing translations): on the administration panel, if you browse to Settings > Languages, you'll see the ones currently supported, and there should be a button near the bottom saying Start translation mode. Once pressed, this will reveal a new footer for the 'translation mode' — you can open it to see a list of all the strings on the current page and provide a translation for those.
It was that simple!
But there was an extra bonus. Translations are actually crowdsourced among all Gallery users. Here is how it works: every time you translate something into a different language, this gets stored in the MySQL database, in the g3_outgoing_translations table. It's stored with a hash that identifies that particular translation. Every now and then, Gallery would then contact an external webservice (http://galleryproject.org/translations/submit) with a JSON-encoded payload representing all the translations you had done so far. This message would have a reasonably primitive (or naïve) digital signature, validating that you had registered to the translation service and that it originated from your Gallery installation and subsequently stored on the remote server.
Periodically (and also at certain specific times, for instance, when you changed the default language or tried to add a new one), Gallery would also trigger a request for updated translations, contacting the webservice at http://galleryproject.org/translations/fetch. It would request the strings for a specific language ('locale') and get a JSON-encoded payload with all the existing strings on the remote database (that had been submitted by all other users), and compare the hashed revision number with the ones currently stored. If there were new translation strings available, these would be locally stored, in the g3_incoming_translations table.
Gallery3 would not use those translations directly from the database all the time: that would be an insane performance hit. Instead, every time a new string was displayed (because the visitor clicked on a page), a request for the translation would indeed be made to the database, but the reply would be immediately cached locally — even if there was no translation. Subsequent requests for the same string would just hit the cache and never the MySQL database, until the administrator manually (or automatically) forced a translation request, which would flush the cache if new translations had been received since the last time. This is a very simple, but quite efficient mechanism: there might be a small overhead when a freshly updated translation is first loaded, but as more people visit the site, the cache would be quickly filled and used instead of the database requests.
The great thing about all this system is that it is already built-in into Gallery3. There is no need to use any kind of external tool, or a specific editor for translation languages, or even a complex mechanism requiring constant updating. While the design of the localisation engine is vaguely inspired by the success and popularity of the GNU gettext internationalisation library, it's a separate system, appropriate for large-scale, crowdsourced translations.
So, if the code is still all there, why am I using the past tense?
Well, the problem is that this whole system depends on the existence of the web services being provided at http://galleryproject.org/translations/ — a hard-coded URL which used to point to the backend server(s) that dealt with all the crowdsourced translations. This service has been sadly discontinued, and I have no idea if it can be reactivated again, or, alternatively, pushed to a different site (this would require changing the URL, of course, but that's something that could be dealt with in a future version of Gallery3). I have no idea if the original source code even exists, or, if it does, if it is open source and can be freely copied and used by the current Gallery3 community. One can reverse-engineer the server-side functionality from the client-side code, of course, but that would be a brand new project. Additionally, the web services on that remote server weren't used only for translations. Automatic updates and plugin installation also required contacting this very server (using different calls). Members of the current developer community are well aware of this issue and it has been briefly discussed — as far as I could follow the discussion — how to address it.
When you switch to a different language (or even turn an existing one into the default one), Gallery3 will always try to contact the remote server to update all languages first before doing anything — an operation which, of course, will always fail. That means that all the localisation and translation functionality, while still present in the code, simply do not work at all. For instance, because I've preserved the whole database from my 3.0.9 version (when http://galleryproject.org/translations/ was still fully operational), I still have all the translated strings for Portuguese in my g3_incoming_translations table. However, I cannot switch Gallery3 to the Portuguese translation, simply because, when attempting to do so, Gallery3 will always try to update the Portuguese translations first, and only if that step succeeds, allows you to switch to a different language. That happens with each and every aspect of the localisation and translation engines: the code is all there, it all works, but it depends upon the existence of http://galleryproject.org/translations/ to provide the required endpoints for those web services — if that server is down (which it is and always will be...), then Gallery3 will simply ignore whatever languages you might have on your MySQL database.
I tried to see if I could somehow add new translations directly to the database and see what happens. Gallery3, however, is not so easily fooled. It may be aware that there are 'new' translations in g3_incoming_translations, but it needs to validate the origin of those translations, i.e. see if they have a valid signature. This will only work if Gallery3 can actually retrieve the public key remotely — which it obviously cannot. Thus, it has no way to confirm that these translations are authentic, and therefore simply ignores them.
It's conceivable that the whole system may be short-circuited — in other terms, instead of failing when the remote server is not present and blocking whatever functionality is provided by it, the code could be changed to 'ignore' these remote calls and just go ahead with reasonable defaults. That would at least allow people to do translations locally (but it would be hard to share them!) and, perhaps most importantly, allow them to switch to an existing, downloaded translation. But that work hasn't been done.
So, if you're interested to look into this, the mechanism is implemented on the client side — i.e. Gallery3 — in the modules/gallery/helpers/l10n_client.php file; obviously I have no clue how it looked like on the server side, which is mentioned on the comments on that file, but I guess that the code for the server side of things has not been preserved...
You would have to check for all the 'failed to contact server' messages, and change the code to pretend that those didn't exist, and basically go on with whatever it's got and just log an error/warning — but not stop. No valid key? No valid signature? Missing translated strings? No problem — log it, but go ahead with what you have.
That naturally would need to be reverted once the external web services are restored at some point, but it might at least allow the current localisation engine to actually do something useful...
zlelik
bwdutton
Hi there. I'm interested in modifying the source code, but are there any section to support non-English languages on the interfaces right now? I'm sorry that I'm really not good at programming, but I want you to ask whether there are something to support multilanguages and how should I do to enable it.