Open robinpaulson opened 5 years ago
I will try to help
I've made an Swedish translation.
Here are some suggestions (maybe there is more than this list):
strings.xml
can be kept ordered and structured
Con: manual copy & paste work (might be cumbersome and error-prone)strings.xml
files will unorderedI'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.
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.
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;).
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.
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:
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.
A first attempt at the groups for strings.xml:
more todo...
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.
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.
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.
Some good suggestions there, @sotpapathe . I like that idea
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.
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.
I like the new grouping but shouldn't the comments be XML-style <!-- -->
instead of #
?
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.
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.....
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.
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.
I added the script as PR #444 .
On a sidenote, I would probably be good to have a CONTRIBUTING section with translation guidelines.
a CONTRIBUTING section with translation guidelines
yes, any suggestions?
Ah, that second link is magnificent. I will certainly adopt the CoC and take a closer look at the contributing guidelines.
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.
I'll add references to both of those in the contributing.md file.
Done, let me know if it needs more (it probably does)
So, I gather anyone can sign up to have their project hosted by weblate service, on their servers. weblate. I'm going to check it out, see if it suits our needs. Apologies if someone mentioned the hosting part and I missed it, this looks interesting,
OK, scrub that. Sorry for the misdirection, apparently we have to pay.
OK, scrub that. Sorry for the misdirection, apparently we have to pay.
Well, have you contacted Michal? Because as per https://weblate.org/en/hosting/ and based on the complexity of the project (no. of strings and so on) you can have it hosted for free (see right column). Another option (don't know how feasible would be) would be installing it somewhere
Did you send in the request so that @orangesunny can get on it? I'll translate it and see if I find some source strings fixes to make one way or the other once the Cov5 CoC is dropped. #451
@comradekingu uff. This time I can say there is no request from Forecastie. 😀
Fill the form, include some info and I will happily do it :)
Oh and thanks! I am downloading the app to right now 🤓😊
@orangesunny I'm interested, we'd be glad to give it a go and see how it works for us. I already have an account, my weblate username is @robinpaulson . I'll let you know how we get on.
Cheers!
Oh and thanks! I am downloading the app to right now nerd_faceblush
Did you fill in the form?
I've spun out the reordering of all "strings.xml" translation files into a separate issue, #455.
I also reordered the French translation to match English. We will discuss the rest of that part of the translation effort there, but keep this issue for anything else related to translations.
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.
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
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!
@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
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
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?
@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
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 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.
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.
@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.
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.
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
@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")
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
windstring 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.
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.
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
@orangesunny As I said before, yes we'd like to use it, sign us up and send the info this way. Cheers.
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 😃
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.