Thank you very much 
!
The other âSyncthing-Androidâ is actually Syncthing-Fork 
.
Iâve observed the following problem with the Android app.
As you can see, device names are displayed as ânullâ in the notification. Theyâre displayed properly when the app is in English. Have you got any idea what the culprit may be here?
This is how the situation looks on Transifex.
I looked at it, but I donât see why the two translations would act differently.
Actually, I was too quick to blame the translations. The problem is about something else 
.
What happens is that if you add the Android device on a different device while also sharing a few folders with it at the same time, the Android device will display a notification asking to accept the new device. Now, if you donât click the notification but rather use the Web GUI (e.g. remotely) to add the device, then you will also get notifications to accept the newly shared folders. In those notifications, the device name will be displayed as ânullâ.
The issue can be seen even better in the screenshot below. The last notification is about the device wanting to connect (with its name displayed correctly), and the newer ones are about the shared folders (with the device name ânullifiedâ).
All in all, this is probably related to the imperfect cooperation between the wrapper and Web GUI.
Can you delete âsi_LKâ and enable âsiâ for Syncthing-android project? Also, please consider to set me as a reviewer for both âSyncthingâ and âSyncthing-androidâ projects. @HelaBasa transifex
1 Like
Just did that, thanks for translating Syncthing!
And incidentally denied a bunch of âgeneric-language_specific-locationâ requests. I consider the necessary effort in handling another translation as higher than the benefit. Of course if someone can make a good case why two variants are different enough, that it impacts users understanding, thatâs another thing. However e.g. Swiss Germans disliking Eszett/Ă (when are you finally getting rid of that monstrosity, dear neighbours? 
) is in my opinion not a sufficient reason to have a separate translation.
Iâve got a related question. Is there any reason why both âPolish (pl)â and âPolish (Poland) (pl_PL)â exist? It seems only the first is actually used, and the latterâs translation is just empty.
No, as imsodin says we try to avoid precisely that. But thereâs some transifex effect where some user joining makes it so all their languages are requested or whatever. Empty translations in transifex are just skipped though when importing.
I can confirm the onboarding experience kind of expects you to check off every language combination you feel confident with. Then later when starting to work on the project, they insinuate you wanted to propose all of them for translation. Not quite what was intended
I just stumbled over https://hosted.weblate.org/, which seems very nice and is free for libre software projects AFAIU. The integration with GitHub is also pretty slick, they have a bot account. Just wanted to know if anything other than Transifex has ever been considered?
Not specifically, but Iâve certainly wanted to consider alternatives any time Iâve interacted with Transifex⊠I think they were just the first/biggest/best/only alternative when we started out back in 2014.
Well they seem to advertise some advanced features, but with the free (?) plan, itâs missing pretty much anything that would help with the actual language content, such as common words / special terms or even fuzzy matching to suggest strings that are 90 % the same as some other.
Such would be helpful for example if we made small punctuation changes and the old string would just get suggested as translation for the new. Then someone could bulk accept the suggestions without even knowing any of the languages. I havenât checked if this is better with Weblate, but given they can integrate directly into the Git repo, it seems more feasible. Changing translations in Git and getting them mirrored back to the web frontend has also been brought up sometimes, maybe that would also work.
Iâve got a question regarding Transifex. Iâm sorry if this has already been asked before, but I couldnât find any concrete information.
Is it possible to view a change history of a whole language? Thereâs a âhistoryâ tab under each string, but Iâd be interested in seeing some kind of a change log of strings in a particular language all in one place.
Just had a moment of inspiration and spare time⊠So after being dissatisfied with some details about Transifex, I went ahead and set up a trial plan on Weblate: Syncthing @ Hosted Weblate
Itâs such a breeze!
Really quick to set up, tons of useful features, great integration with the VCS (I went for the GitHub Pull Request contribution model, but there are others), libre software. Only roadblock so far was that the existing translations for Spanish and Spanish (Spain) could not both be imported, so I quickly excluded lang-es.json for now to get going.
It currently points to my GitHub fork at GitHub - acolomb/syncthing at weblate to not disturb the main repo. That can be changed easily though. It immediately showed me common errors (mismatched punctuation, leading or trailing spaces, same translation word, âŠ) for the German strings, some with a simple âFix Stringâ button. Advanced features such as merging translations between different project components, importing machine-based translations or sharing the common global Weblate Translation Memory (not yet signed up for) are in stock for us. Just soooo much more than Transifex gives us.
And all that FOR FREE. I signed up for a 14-day trial plan with âEnterpriseâ level features. For public, libre projects, one can apply to get forever-gratis access on âAdvancedâ level, which should more than cover our needs for Syncthing. And it is itself libre software, so we could still spin up an own instance should the need ever arise.
From my POV, definitely a worthwhile improvement over Transifex. First we should have some more voices from developers and translators whether the solution would be acceptable. If so, Iâd apply for switching to the no-cost âlibreâ plan. Then weâd need to work out a transition plan, taking into account how Transifex can interact with it for a mid-term solution involving both platforms.
What dâya think?
(If anyone wants to take a look what the thing looks like with admin permissions, feel free to contact me and I will try to give elevated access to your Weblate user.)
Iâve got no previous experience with the platform (as the only I have used so far are Transifex and Crowdin), but judging by the first experience, it looks very clean (and also loads and performs super-fast in comparison to the other two).
Just a few questions:
-
Does the translation system work in the same way as on Transifex? What I mean is that currently there are teams for each language with different permissions, e.g. only âmodsâ (donât remember the exact name) can review and change already reviewed translations while normal translators can only add missing ones, etc. Others can leave comments and/or suggest alternative translations. There is also translation history available for each string. Is the new platform organised in a similar manner? Does it offer same or similar features?
-
Is the âfix stringâ feature optional or automatic? While there are obvious mistakes like double/leading/trailing spaces and such, there are also legitimate differences when it comes to punctuation between different languages (e.g. in Korean, a colon is never used after a full sentence). Transifex often complains about âglossaryâ words not matching showing an exclamation mark next to the string but it also offers a button to ignore it for the current translation. Is there a similar way to ignore such automatically detected âerrorsâ here?
-
Moving to a new platform would mean that all current translators would have to sign up and start from scratch, right? Is there no way to automatically transfer the current translator groups (and, if possible, with their hierarchy)?
-
Does the new platform offer better notifications about newly added strings? Transifex is horrible in this aspect, as you need to log in in order to actually see whether there have been any changes or not. Ideally, it would be fantastic to be notified more directly, e.g. by e-mail, so that translators can react more quickly to any changes.
-
Would the transfer involve everything Syncthing-related, meaning both Syncthing and Syncthing-Android? When it comes to the two, one problem right now is that many strings are identical in both of them, but because the projects are completely separated, the same sentences can be (and in many cases are) translated very differently. Does the new platform, by any chance, offer a way to âlinkâ translation strings between different projects (so that once translated in Syncthing proper, the particular string would automatically be used in Syncthing-Android too) or am I asking too much?
-
How long has Weblate been around and how well established is it in comparison to Transifex?
I hope the questions are clear and not too difficult. Big thank you for doing the research nevertheless!
IMHO this is not a positive, in fact itâs one of my primary annoyances with Transifex.
Itâs been a never ending story that someone requests a language, does (some) initial translation, and now they are the âcoordinatorâ of that language. They disappear, other people join, but now these people canât change existing translations or do many other things, so they reach out and need help to be promoted. I have scripts and stuff to periodically promote everyone to reviewer and so on to make this work.
From my point of view itâs better if this is all more hands-off, at least unless a specific language team decides to do something more structured. I suspect that will be a minority of cases.
Otherwise, in general, my interest stretches only to the point where it must be possible to download the JSON files in an automated manner, like we do with Transifex. As long as that works and the whole thing doesnât create manual busywork for me, Iâm a happy camper. 
Let me try to answer each point in turn.
-
In short: Yes, if needed. There are different possible workflows and a fine-grained role-based access management system. If we do want to distinguish between translators and reviewers, the review workflow can be enabled.
-
So far Iâve only seen the âfix stringâ feature as a suggestion for manual approval. Maybe it can be forced to apply automatically, but I guess we donât want that. Each warning has a âDismissâ button, which sets a flag, optionally for all languages.
-
I donât know about exporting users from Transifex. You can sign in using GitHub (among others) on Weblate, so many users should be able to switch over easily if already involved there. Invitations can be sent for new users given the e-mail address.
-
Notifications are a real pain point on Transifex. Weblate has fine-grained options available per user account and per project. Sending e-mails is the default notification method.
-
Weâre free to manage both projects there, they can be set up as different resources under the same project. Sharing strings between components is a supported workflow. Not quite sure if it can happen automatically, but at least youâd get an obvious hint when there is a matching string. Part of our problem is probably that the original strings donât match, which cannot be fixed easily on the translation level.
-
The start page currently says
used by over 2,500 libre software projects and companies in over 165 countries. And:It all started in 2012.
1 Like
Direct download of a JSON file per language is possible, e.g.: https://hosted.weblate.org/download/syncthing/gui-strings/de/
The whole thing is based on a Git repository per component internally, which can be accessed through native tools to do anything you like. Fetching updated language files from the upstream project can be automated using hooks for GitHub and other platforms. Deeper integration like pushing back changes can be done to further reduce chores, but of course the current script based solution will still work fine.
1 Like
That all sounds perfectly adequate.
Bonuspoint: itâs FOSS