Fix translations

[robinpaulson]

In the last few months, we've made many small changes to Forecastie. Some of these have adjusted the user interface, however slightly. However, we haven't updated the translation strings to match. I think it's important we do so, but am unsure how, given the existing Transifex account is not an option.

Suggestions please.

[Aresiel]

I will try to help

[Aresiel]

I've made an Swedish translation.

[FridoDeluxe]

Here are some suggestions (maybe there is more than this list):

1. Edit the strings.xml manually (GitHub online editor, Android Studio or any other editor)
   Pro: strings.xml can be kept ordered and structured
   Con: manual copy & paste work (might be cumbersome and error-prone)
2. Use the Translations Editor in Android Studio
   Pro: nice point-and-click UI, automatic highlighting of missing texts and not translatable texts
   Con: translators need Android Studio, content of strings.xml files will unordered
3. Open a new account on Transifex or another web-based translation service (there are also FOSS tools to host your own translation web app, but this needs an additional web server and makes things too complicated)
   Pro: web based overview of translation status per language, easy for non-coders
   Con: might be confusing with the current abandoned Transifex account, risk of loosing again access to an external web service
4. Automatic translation tools (for example scripts that utilize Google Translate like mentioned in https://stackoverflow.com/questions/44477221)
   Pro: every language is possible
   Con: no quality control, bad quality especially for longer texts

I'm personally in favour of 1. and 2., but everything on this list has its advantages. I wouldn't use 4. to add new languages, maybe only if a few texts are missing for a language. But committing texts you don't understand and can't verify feels wrong ...

Concerning the ordered strings.xml file: Currently all files seems to be based on the default English file and share the same logical order of entries and are grouped by empty lines. Using the Translations Editor (and maybe other external tools) this structure will be lost, new translation entries are simply added to the end. Technically this is not a problem, but this makes it harder to work manually with these files.

Important in this case is also which tool is popular with the current/potential Forecastie translators.

[robinpaulson]

I'm not a fan of 2., for the reasons you mention, it's very useful to have the lines associated as blocks, separated by empty lines. We shouldn't arbitrarily discourage those who code by text editor.

I think losing access to transifex or wherever in future isn't necessarily a bad thing, would it be a major problem? At the worst, we are back to where we are now, plus we can always set up another, even if that's not ideal. I am OK with setting that up, then making sure Martykan and/or a successor has the details, in case I decide not to take part in Forecastie any more.

No. 4 is interesting, but as you say needs another approach as well, which means one of the other suggestions you list.

[Gitsaibot]

Maybe you can ask the guys from weblate if they support your project. It's free for open source projects. I did it for "Etar" and there were no problems;).

[FridoDeluxe]

We shouldn't arbitrarily discourage those who code by text editor.

Yes, you're right. Maybe we need to check and refactor all xml files at next opportunity, because even the English on is not perfectly structured anymore.

I think losing access to transifex or wherever in future isn't necessarily a bad thing, would it be a major problem? At the worst, we are back to where we are now, plus we can always set up another, even if that's not ideal.

You're right again. Manually editing combined with using an online translation service seems to be a good solution.

Maybe you can ask the guys from weblate if they support your project. It's free for open source projects. I did it for "Etar" and there were no problems;).

Thanks for the information. Both Transifex and Crowdin also offer free accounts for open source projects. I only know Transifex from a translator's persepective so I can't say which service is most suitable for Android/Github. At least Transifex has the advantage that there are already 53 persons which helped to translate Forecastie in the past.

[robinpaulson]

We shouldn't arbitrarily discourage those who code by text editor.

Yes, you're right. Maybe we need to check and refactor all xml files at next opportunity, because even the English on is not perfectly structured anymore.

I think this is a good starting point. I could do the following for the english version:

• break the strings.xml into blocks
• add short comments at the start of each block, explaining what that block does

then as we do the same to more and more of the other translations, missing/wrong strings will become more obvious.

once the manual method is sorted, we can add in an online translation service, the comments will encourage translators not to change the order of individual strings.

[robinpaulson]

A first attempt at the groups for strings.xml:

• Action bar
• Generic
• Units
  ** Temperature
  ** Length
  ** Pressure

more todo...

[FridoDeluxe]

then as we do the same to more and more of the other translations, missing/wrong strings will become more obvious.

The Translations Editor inside Android Studio also highlights missing strings. Currently most translatable strings are missing in one or more languages.

add short comments at the start of each block, explaining what that block does

once the manual method is sorted, we can add in an online translation service, the comments will encourage translators not to change the order of individual strings.

Transifex (source) and other translations services support already XML comments. But they are meant as an explanantion for the directly following translation entry, this is already in use in Forecastie's strings.xml. Comments at block start maybe need to be separated by a blank line.

Do you want to manually copy texts from the online translation service? I think all services also provide GitHub integration and automated PRs, but I have no experience if the order of the XML files will be respected.

[robinpaulson]

As I said a few comments back, making sure we can edit translations manually is important to me. I think we should sort that first, then whichever other method we use. Think of it as analogous to the principle that most Unix-like software starts with a library, then a command-line utility, then a GUI application. It's easier to do the basics first, then the more complex later, rather than the other way round. I'm sure the online/more fancy software can do this, we'll get to it later and use those capabilities then.

[sotpapathe]

I'm also in favor of being able to manually edit translations. Keeping the structure is also important as it makes it easy to diff against the English translations and quickly find any new strings that have been added.

I used vim's diff mode for comparing the Greek and English translations for PR #443 and the work was quite painless and error-safe. Lines that haven't been translated yet are easy to spot since they appear to have no diff, while lines in the wrong place have a greater diff than expected. Adding this here as a potential workflow for updating translations.

[robinpaulson]

Some good suggestions there, @sotpapathe . I like that idea

[robinpaulson]

In which case, reordering the lines would be a very useful step forward in tidying the translations. I mentioned previously about putting them in like-minded groups, making them all in the same order is probably the next step after that.

[robinpaulson]

I've moved around the strings so they are grouped in what I think is a better way. I'd appreciate anyone who's interested taking a look and giving some feedback/suggesting changes.

[sotpapathe]

I like the new grouping but shouldn't the comments be XML-style <!-- --> instead of #?

[robinpaulson]

Yes, they probably should. Oddly, it builds fine; I guess the parser is fairly liberal in what it allows. I'll get right on it.

[robinpaulson]

OK, done. Unfortunately, @sotpapathe this all means your good work reordering the Greek strings.xml has been undone. Sorry about that, I should have got on to it months ago.

I'll suggest to leave it for a while, there may be other changes as we figure out how best to group the strings. Unless you feel like doing it multiple times that is.....

[sotpapathe]

No worries, I can update the order when we have finalized the grouping. In the meantime I am working on a small python script that will display which strings still need to be translated for each language.

[robinpaulson]

I am working on a small python script

Marvellous, keep us posted on that. If you're willing to GPL3 it, I'll put it in the git repo.

[sotpapathe]

I added the script as PR #444 .

On a sidenote, I would probably be good to have a CONTRIBUTING section with translation guidelines.

[robinpaulson]

a CONTRIBUTING section with translation guidelines

yes, any suggestions?

[adriaaah]

a CONTRIBUTING section with translation guidelines

yes, any suggestions?

Maybe this could help, however that one is full of ❤️

[robinpaulson]

Ah, that second link is magnificent. I will certainly adopt the CoC and take a closer look at the contributing guidelines.

[robinpaulson]

OK, I've added a CoC as at contributor-covenant.org, suggestions of improvements of course welcome. I'm not sure which translation-specific guidelines would be helpful though, beyond linking to the Transifex page or pointing out the Python script you added. I'll add references to both of those in the contributing.md file.

[fAntel]

I might be late but I have one on my mind about 4. There is a tool android2po licensed with BSD license. This tool is converter from strings.xml into .po files and vice versa. .po files was invented with gettext which is widely used in *nix apps and there are a lot of apps to edit .po files.
Pros: a lot of apps to edit translations files
Cons: the tool breaks order of strings in the xml files.

And about breaking strings in blocks. It might be better to break strings in files. For example, add strings_units.xml with only units, strings_graphs.xml with string for graphs and so on. In that case order of strings won't be matter.

[comradekingu]

Weblate has support for Android strings directly, no need for PO files.
Edit
https://docs.weblate.org/en/latest/formats.html#translation-types-capabilities
https://docs.weblate.org/en/latest/formats.html#aresource

[robinpaulson]

add strings_units.xml with only units, strings_graphs.xml with string for graphs and so on

oh wow, is this possible? that could help no end. cheers!

[robinpaulson]

@comradekingu

Given you've very vocally and publically said you don't agree with the CoC and won't contribute while we use it, could you desist from posting on Issues? They are no more or less a form of contribution than code pull requests.

Thanks

[comradekingu]

https://github.com/osmandapp/Osmand/tree/master/OsmAnd/res/values uses multiple different resources.
https://developer.android.com/guide/topics/resources/string-resource.html#String

Off-topic defence

I am not in https://github.com/martykan/forecastie/graphs/contributors despite my attempt https://github.com//pull/451

(If your view of meritocarcy differs from mine, I do suggest https://ethicalsource dot dev from the same author as the CoC this project has. You will find it isn't libre software. It too attempts to combat some perceived bias by entering a non-perceived bias by default, only this time those biases ensure everything is incompatible.)

You have no way of knowing anyone "pledges" to having their conduct codified either. Much like you could ban me anyway, sure, you have a text file saying you can do so, pretending that it is "the community".

"our community", "the overall community"

Nobody was asked(?), in an already existing project, that uses contributions from existing projects.
To my knowledge, that is not how things work, and I imagine you would further lose contributors over it.
I never disagreed it wasn't in your power to do so, I just disagree I need to agree to grant you that moral high-ground in doing so.

Am I incorrect in assuming "community leaders" are also project leaders/maintainers?

So much for "open, welcoming, diverse, inclusive, and healthy community."

Awaiting "and will communicate reasons for moderation decisions when appropriate." Unless in further authority, you haven't taken the pledge yourself?

Like many don't read CoC's, I will freely quote the seldom read community guidelines of GitHub:

https://help.github.com/en/github/site-policy/github-community-guidelines

We encourage you to be welcoming to new collaborators and those just getting started.

Communicate with empathy - Disagreements or differences of opinion are a fact of life. Being part of a community means interacting with people from a variety of backgrounds and perspectives, many of which may not be your own. If you disagree with someone, try to understand and share their feelings before you address them.

[huuhaa]

Just quick question to make sure. Is this official transifex translation project:

https://www.transifex.com/forecastie/forecastie/

Asking cause there's no Finnish at the list (requested it thought), but at the app "most" / some parts are already translated to Finnish. So I assume that even with Finnish accepted to the transifex there would be no existing translations done there, or will you when accepting upload current Finnish language file to transifex also?

[robinpaulson]

@fAntel if it's not too much effort, would you mind forwarding a link on how we would do this?

And about breaking strings in blocks. It might be better to break strings in files. For example, add strings_units.xml with only
units, strings_graphs.xml with string for graphs and so on. In that case order of strings won't be matter.

cheers

[fAntel]

I don't know why localization page said that all strings must be in strings.xml because another page said

Because each resource is defined with its own XML element, you can name the file whatever you want and place different resource types in one file. However, for clarity, you might want to place unique resource types in different files.

So you just need to create new *.xml file at res/values with tag and aapt will compile all of them in one strings table in resources.arsc and put it into apk.

For clarity I advice to start all that files with strings_.

I've tried to find example and I'm surprised why it approach unpopular. I've found two example (DuckDuckGo and OpenLauncher) but both user different files only to differ translatable and non-translatable strings. I know this approach works because we use it at work but the project is close sourced and I can't share code. But we have almost ten files with strings resources and it all works fine.

[fAntel]

Oh, I forget one thing. Before splitting strings into different files we need to check that the tool selected for translators supports strings in several files. I know such tools exists but it could be non-free (in both senses). And I checked the python script written by @sotpapathe only supports strings.xml. But it is easy to update it to check all files with <string> and without translatable="false" parameter.

[sotpapathe]

@fAntel It's indeed not too hard to update the script to handle multiple files per language. I could do it once a format is agreed on. I agree that strings_*.xml is a good Idea.

[robinpaulson]

Last night I used the script "reorderAll.sh" in the tools directory to organise all the strings in the various strings.xml files. I also updated the template to account for new additions since that script was written. It's helped me lots, it shows gaps in the various translations.

There's a small chance I have broken some of the translation files, so please do check to see if there are any strings missing from any languages you know.

[robinpaulson]

different files only to differ translatable and non-translatable strings.

this is a useful idea, we could put all the icon strings in one file

[fAntel]

@robinpaulson I think about one more thing. In many places we use string concatenation like
context.getString(R.string.wind) + ": " + new DecimalFormat("0.0").format(wind) + " " + localize(sp, context, "speedUnit", "m/s") + (widgetWeather.isWindDirectionAvailable() ? " " + MainActivity.getWindDirectionString(sp, context, widgetWeather) : "")
which is not the best solution for translators. In some locale could be another order of words, another characters for colon or lack of white spaces. Better approach is use string format. For this example we change wind string from
Wind
to
Wind: %1$s %2$s %3$s
And use it like:

String winSpeedValue = new DecimalFormat("0.0").format(wind);
String windSpeedUnit = localize(sp, context, "speedUnit", "m/s");
String windDirection = widgetWeather.isWindDirectionAvailable() ? MainActivity.getWindDirectionString(sp, context, widgetWeather) : "";
context.getString(R.string.wind, winSpeedValue, windSpeedUnit, windDirection)

So a translator could change the order and so on for this string like Wind%1$s%2$s %3$s to get Wind1.2m/s S

This is just a proposal and maybe it deserves its own issue.

[robinpaulson]

or lack of white spaces

this came up already last year, apparently the French use a colon differently to the English, which required a slightly bodgy solution in the strings.xml

this suggestion has merit at first glance, I'll have a think about it, do leave more info here if you think it will help. and yes, a new issue is a good idea.

[orangesunny]

Hi all,
I stopped following this thread, waiting for your hosting request. As nothing came, I am unsubscribing and leaving here the link in case you would like to set up the Forecastie translation project: https://hosted.weblate.org/hosting/

And yes, you can use Android translation files in Weblate, no conversion is needed. 😃

All the best,
Benjamin

[robinpaulson]

@orangesunny As I said before, yes we'd like to use it, sign us up and send the info this way. Cheers.

[orangesunny]

Hey @robinpaulson, just click the link in my previous comment. :) Login and set everything up the way you want. I will only agree that Forecastie is eligible for Libre hosting afterward. So go on 😃

[ildar]

I followed the https://github.com/martykan/forecastie/blob/master/CONTRIBUTING.md#translations and contributed to Transiflex. Is it going to be lost?

[robinpaulson]

I followed the https://github.com/martykan/forecastie/blob/master/CONTRIBUTING.md#translations and contributed to Transiflex. Is it going to be lost?

No, I will copy any outstanding strings across manually. Your contributions plus those of others

[fAntel]

@robinpaulson as I can see strings for default locale (English) have been split into several files with format strings_*.xml and all translations have one strings.xml file in the corresponding value-* folder. This is final variant for now? Could we ask @sotpapathe to update translation-progress.py script?

[robinpaulson]

It probably is for now. I've been meaning to update the script, but have slacked off.

[sotpapathe]

I'll be pretty busy for the next month but I will update it if I find some time.

[sotpapathe]

Updated the translation script in PR ##558. It should also handle any new strings*.xml files added in the future.

[umoenks]

Hey, I manually updated German translations in PR #571. Is that OK so far?