Should Syncthing have all kinds of localized translations?

What I mean by localized languages is e.g. American- and British-English, instead of just English. There’s been quite a few such requests recently, and also in the past. I usually denied them for ow if we already have the “generic” variant and a quick internet search didn’t turn up clear hints that the languages are clearly distinct. As I am keeping an eye on transifex, I’d like to know whether there’s a consensus here on this issue:

How should language request for localized variants be treated?

Non-exhaustive possible stances are to accept everything that’s requested, or to only accept localized languages if they differ significantly (understanding of the other variant is difficult).

So I think it makes sense in some cases, for example Portuguese (Brazillian), etc, as they are fundamentally different languages.

But wtf is English (German). These ones should be refused as they make no sense. I doubt they will have meaningful maintenance.

What kind of localised translations have people been usually requesting specifically? Just curious.

English (German) just came in, which doesn’t make much sense to me.

Other examples are Brazilian and Portugese Portugese, British and Australian English (that’s one I am also not convinced about), three Chinese variants.

I only just now had a look at the transifex download script, and it uses a manual list of languages to filter those on transifex. Makes sense for very incomplete language. However it’s not an option to approve languages on transifex and then not add them there - that would be a waste of translator time.

That might have been my bad, sorry. I just clicked on any permutation in the suggested list that I felt like I could contribute to. There was no intention to actively start or suggest such a translation should exist.

I guess that it is probably more of a case-by-case basis. The Chinese variants are definitely different, e.g. the GUI seems to use the same vocabulary for China and Hong Kong, but the characters are simplified in the former and traditional in the latter, while in the Taiwan one, the entire vocabulary is different. On the other hand, the differences between the British and Australian GUIs seem to be minimal (If any? They seem to be the same on the surface…).

I agree that if we do not want to have just every possible variant, it’s going to be a case-by-case decision. And I can imagine that some people could get quite upset by rejections (some people feel strongly about their local variant). I don’t mind if I or anyone else makes such decisions, I just want to know whether restricting local varaints to some degree (and maybe which degree) goes totally against project consensus or not. There seems to be one point of consensus so far: We don’t want localized language variants that aren’t a native language at that location (e.g. English-Germany).

I would agree on the “case by case” idea in general, with the guiding principle that a request for a variant be considered primarily when the existing version is not comprehensible to the person requesting the variant. (I.e. the Chinese variants mentioned above)

In cases where the differences are primarily ‘idiomatic’ like some of the US vs UK things that people make jokes about (i.e. British inkeepers offering to “knock up” female guests in the morning, as opposed to a ‘wake up call’) it might be sufficient to look at whether a given variant request might be handled by changing any language in question to something more ‘standard’ / easily understood - i.e “look in the engine area” not “look under the hood (or bonnet)”

ex-Gooseerider

2 Likes