Why not use a translation service

You may be wondering why we're not using a third party translation service such as Weblate, Transifex, CrowdIn, Poeditor, etc for managing Panopticon translations. This page will answer those questions for you.

Cost

All translation services cost absurd amounts of money considering the very scant computation power and storage needed. They charge based on the number of translation strings, words, characters, or languages, or a combination thereof. Our project unfortunately has a lot of language strings, some of which are quite lengthy, which means that the cheapest tiers of these services are already not enough. This places us into quite expensive territory.

Moreover, any features which would make using a service interesting – such as integration with machine translation services, glossaries, etc – are either encumbered or completely missing unless we get the highest paid tier, usually to the tune of thousands of Euros per year.

Panopticon is free of charge software. Spending more money for its translations than we pay for hosting our own company site, and disseminating our company's paid software combined is out of the question.

FOSS selection criteria are inconsistent

Some of these services offer free of charge accounts for Free and Open Source Software (FOSS). However, the selection criteria for FOSS seem to be inconsistent with the definition of FOSS.

Some services, for example, refuse to offer a free tier if the FOSS project is tied to a company that also releases for-profit software, or if the FOSS project is not backed by a non-profit. Others impose arbitrary requirements such as service advertisement clauses, or account activity clauses, which are not only problematic but also put into question the continued availability of the translation environment.

Finally, even for the few services which do not have any such restrictions, we are unwilling to trust their continued commitment. It's not out of paranoia; we've been burned before when Transifex reneged on what “free hosting for FOSS projects” meant and asked us to either advertise them for free, or pay them absurd amounts of money.

Integration is a mess.

Most services we've found have a problematic approach to integration. They can neither pull, nor push, the language files from / to the repository directly. This requires us to write convoluted automations to send the updated source language files to the service, and to pull the updated languages back to the repository. Using this approach also loses the attribution of the language to the translator, misleading users into asking us about translations in languages we don't speak. And since we do not know who the translator really is, or know but do not have their GitHub handle, we cannot possibly notify them which leads to possible issues with translations remaining unfixed. Ugh.

With the very services which integrate with GitHub directly, we've had a few problems. First of all, we've noticed inconsistencies on what constitutes a valid, usable translation file and what the service considers one, leading to some imports failing miserably.

With all services we have seen one of the following issues. Sometimes, we would add a string in English, and it would not appear in any other languages – with different strings not appearing in different languages, meaning it is not an error in the source language INI files. With some third party services we saw inconsistent application of the double quotes surrounding the language string, which means that some strings were unrecognised, and some were added with the double quotes around them (and would not work if translated without the double quotes around them). Finally, all third party services seem to think that the Joomla! INI language format requires converting a single double quote " to "_QQ_", something which has not been true since Joomla! 2.5 was released in 2012, which meant that we had to provide a conversion step before sending a language to the translation service and again after pulling the language back to the repository, with everything that entails for reliability.

Overall, the quality of the itnegration was miserable and negated the reason for using a translation service. In the end of the day we want something which works consistently, and results in language files we can apply effortlessly. If we have to reinvent the wheel, we might just as well do without a translation service.

Why not self-hosted?

We've tried that, but it was not very successful as we have already discussed.

Yes, that article is written in 2018. We tried the same thing again in 2023, both straight-up installation of Weblate, and using Docker. Both installations failed to cleanly update from version 4 to 5, leading to a broken installation which neither worked right, not could it upgrade cleanly.

That, combined with the integration issues explained above, led to the decision NOT to pursue this option.

Where does that leave us?

We do understand that translation services can lower the barrier of entry for translators, but the trade-offs are not worth it. In the end of the day, if it doesn't work well, or is beyond our financial means; that makes it impractical.

If anyone would like to disagree and suggest that we use any, or a certain, third party service we are happy for that idea AS LONG AS that person is ready to commit to pay for the cost of the translation service for years to come, volunteer to write and maintain the integrations necessary, and commits to providing support to translators who will be bumping into problems with the service or its integration. If the person making that suggestion is unwilling to put their money and time where their mouth is, they cannot possibly ask us to do it. We already put our time and technical knowledge in this software. We can't put money and time we don't have into a tertiary façet of the software, smothering its development and jeopardising our continued existence as an independent software development company.