Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Norwegian Bokmål translation #77

Merged
merged 12 commits into from
Aug 13, 2021
Merged

Norwegian Bokmål translation #77

merged 12 commits into from
Aug 13, 2021

Conversation

comradekingu
Copy link
Contributor

Consider using Weblate :)

@falzonv
Copy link
Owner

falzonv commented Jun 29, 2021

Hello,

Thank you for the start of translation and suggestion, Weblate looks interesting but I do not plan to implement it for my project in a near future (no issue for me if my launcher only has a few translations, the most important part to use it is the applications list and it is already displayed using the system locale).

For this reason, and because we seem to have very different writing styles and expectations (as per PR #78), I am afraid the experience would be frustrating for both of us.

Therefore I prefer to close this PR and come back to you if someday I put Weblate in place to see if you are still willing to do the Norwegian translation of Discreet Launcher.

Best regards.

@falzonv falzonv closed this Jun 29, 2021
@comradekingu
Copy link
Contributor Author

comradekingu commented Jun 29, 2021

This is the full translation, not half a translation.
If your app doesn't have enough translations it won't be listed on F-Droid in "Latest".
I don't like that either, but I am trying to help in that regard.
We have standards for nb_NO, http://i18n.skulelinux.no/nb/Fellesordl.eng-no.html and this PR follows the entire corpus of other translated Android apps.

This PR has nothing to do with Weblate, as such, what you are preventing is a perfectly good nb_NO translation from reaching only an audience of nb_NO users…
What would OTOH be different if I did the exact same thing on Weblate?

Edit: If you were to put it on Weblate in some capacity, my translation would be auto-imported (provided it wasn't actively excluded like here). Is there some misunderstanding here?

@falzonv
Copy link
Owner

falzonv commented Jun 29, 2021

If your app doesn't have enough translations it won't be listed on F-Droid in "Latest".

=> My application is already listed in the "Latest" tab.

This is the full translation, not half a translation.

=> There are two other XML strings files for help and settings in the same folder than the strings.xml file you translated, both of them are much bigger than this one.
After several tries struggling to manage a too large strings.xml file, I found that what works for me is to split it like this.


Regarding Weblate, maybe it was a misunderstanding from my side.
Some people contributing to lots of projects in parallel may prefer to work using always the same tool as it is easier for them to manage (which is quite legitimate and understandable) and I thought it was your case with Weblate.

If you are able and willing to maintain this Norwegian translation (the 3 strings file) over time even if it is managed outside Weblate, then indeed there should be no major issue to add this translation.


An idea that I would like to try is a never-closing issue called "Translations update" to which translators could subscribe and on which I would post the added/modified strings when there are updates to do (that way, the translators do not have to watch the repository or check the list of commits).
=> For updating the files, the translators could either create pull requests or reply with the translation in a comment for me to copy-paste directly in the related strings file.
=> Once modifications are integrated, related comments would be hidden to keep the issue readable.

Would this process be ok for you?


Another question: is there a significant difference between "values-nb-rNO" and "values-nb"?
Both include "nb" which, I guess, means Norwegian Bokmål.
If this is close enough, I would prefer to use the second one for consistency with my other translations (2-letter locale codes).


Finally, the "translation_credit" string is intended to contain something like the following example (to be translated in the target locale) which will be displayed just below the About section of the Settings.
The rationale behind this is that I don't speak a word of Norwegian and want users that could come here on GitHub to know it upfront to avoid disappointments and confusions. It is also an occasion to mention the translator which, in my opinion, is good.

Norwegian translation provided by Allan Nordhøy.
If you would like to contact Vincent (developer), please do so in English or French.

I think I will a template for this in the "strings.xml" file as a comment, it will be more clear.

@falzonv falzonv reopened this Jun 29, 2021
<string name="license_link" translatable="false">https://gnu.org/licenses/gpl-3.0.txt</string>
<string name="website_description">Besøk nettsiden for å sjekke kildekoden, andre progsjekter, og innrapportering av feil</string>
<string name="website_link" translatable="false">https://vincent-falzon.com</string>
<string name="translation_credit"/>Norsk oversettelse ved Allan Nordhøy</string>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<string name="translation_credit"/>Norsk oversettelse ved Allan Nordhøy</string>
<string name="translation_credit"/>Norsk oversettelse ved Allan Nordhøy, <epost@anotheragency.no></string>

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<string name="translation_credit"/>Norsk oversettelse ved Allan Nordhøy</string>
<string name="translation_credit">Norsk oversettelse ved Allan Nordhøy, [email protected]</string>

No problem of course if you want to add your mail :-)
Just fixing the "empty tag slash" (since it is not empty anymore) and removing < and > that would cause issues with the XML parsing (just tried with it and it failed to compile, even when adding \ which is quite strange by the way).

By the way, to avoid future confusions I changed back the "empty tag slash" to <string name="translation_credit"></string> format in the English version.

@comradekingu
Copy link
Contributor Author

comradekingu commented Jun 30, 2021

Back with a full translation, thanks for clearing that up.
Good that it is in "Latest". Don't know if more translations gives one of those double-fields, but having a URL to a translation platform to use will give a "translation" field in the info, (and possible an entry in the app itself) which attracts translators.
I am fine with either, but Weblate is the better tool, producing better results.
As long as strings are appended to the file rather than just added in situ, it is sort of manageable.
The problem is catching changed strings, but I guess you could link relevant commits to that effect from the relevant "translators" issue.

nb_NO is the official standard, going back to the System V days.
I went with <string name="changelog_folder">changelog-nb</string> to keep it consistent in the user realm.
Hopefully that works.(?)

Added the translator field, with a possible e-mail address for the feedback loop. The easiest way to contribute is always preferable IMO. In this vein, it is harder to make small changes or improvements if it means opening up a new PR each time.

@falzonv
Copy link
Owner

falzonv commented Jun 30, 2021

Back with a full translation, thanks for clearing that up.

=> Great, thank you!

I guess you could link relevant commits to that effect from the relevant "translators" issue.

=> Yes, this is exactly how I plan to do it :-)
If GitHub allows it, I would even like to link directly to the modified strings file(s) in the commit diff (so no need to scroll/search).

The easiest way to contribute is always preferable IMO. In this vein, it is harder to make small changes or improvements if it means opening up a new PR each time.

=> Totally agree. PR will be fine when there are many updates, but a bit cumbersome if there are just minor changes.
I will think about ways to make it easy in the "translators" issue, I am sure there should be a good solution.


nb_NO is the official standard, going back to the System V days.

Yes, but listing locales from an Android emulator (code snippet at the end of this message if interested), I see the following:

...
naq    ==> Nama
naq_NA ==> Nama (Namibia)
nb     ==> Norwegian Bokmål
nb_NO  ==> Norwegian Bokmål (Norway)
nb_SJ  ==> Norwegian Bokmål (Svalbard and Jan Mayen)
nd     ==> North Ndebele
nd_ZW  ==> North Ndebele (Zimbabwe)
...

So if we use "values-nb", it would include both "nb_NO" and "nb_SJ" at the same time instead of only "nb_NO".


I went with <string name="changelog_folder">changelog-nb</string> to keep it consistent in the user realm.
Hopefully that works.(?)

No, this one is a special string to select the correct changelog folder in the assets folder ("changelog-en" or "changelog-fr", I use a script to replicate these from the fastlane folders of F-Droid release notes).

For me there is not real added value to have this part translated, so it can stay at "changelog-en" (or "changelog-fr" if it is more relevant for some translations).


Added the translator field, with a possible e-mail address for the feedback loop.

Ok, I leave that to you for the e-mail address :-)
However, I would appreciate to also have the second line if you don't mind:

If you would like to contact Vincent (developer), please do so in English or French.


For information, this is the loop I used to list the available locales in the extract above (produces 645 lines on Android 11).

final Locale[] availableLocales = Locale.getAvailableLocales() ;
for(Locale locale : availableLocales)
{
    System.out.print(locale.getLanguage()) ;
    if(locale.getCountry().isEmpty()) System.out.print("   ") ;
        else System.out.print("_" + locale.getCountry()) ;
    if(locale.getLanguage().length() == 2) System.out.print(" ") ;
    System.out.println(" ==> " + locale.getDisplayName()) ;
}

@falzonv falzonv mentioned this pull request Jul 1, 2021
@comradekingu
Copy link
Contributor Author

comradekingu commented Aug 9, 2021

@falzonv nb_SJ is never used. Norway has a top level domain for the Bouvet island too, and all sorts of strange stuff.
There is no course of action where people wouldn't use English to contact you with that name (from nb_NO locale), or French if not.
Everything updated now. (Removed icons since I saw that in the changelog.)
Good to go?

@falzonv
Copy link
Owner

falzonv commented Aug 10, 2021

Hello,

Great, thank you for the update!

Yes the icons were causing issues with some phones (showing strange Chinese characters, like in ticket #99) so I decided to remove them to avoid device-specific issues.

nb_SJ is never used. Norway has a top level domain for the Bouvet island too, and all sorts of strange stuff.

=> Ok, I didn't know that is was not used. To be honest I would still prefer to use "nb" for consistency with other languages being on 2 characters ("en", "fr", "ru"), is it really a problem for you?

There is no course of action where people wouldn't use English to contact you with that name (from nb_NO locale), or French if not.

=> Not so sure about this because I already had a Russian ticket in my queue a couple of weeks ago (even with the text).

I was not talking about people contacting me about the translation, but more about reporting issues or suggesting improvements.
But ok, let's give it a try like this and see in 2 or 3 months.
If there were Norwegian tickets we will add the sentence, otherwise I will remove it from the Russian translation as well.

Best regards.

Co-authored-by: Vincent Falzon <[email protected]>
@falzonv
Copy link
Owner

falzonv commented Aug 11, 2021

Regarding the changelog:

I would translate it if it was on Weblate, but it isn't crucial and it is better to have in English that if it were to go missing due to no translations.
I might translate the fastlane files, don't know why it isn't generated from those?

The changelog is indeed generated using the fastlane files, I use a script (locally on my computer) to replicate these files in the related Android "assets" folders before applying the final commit of a release.

But I want to keep the release notes only in languages that I can write myself (that is, English and French for now) to not slow down the publishing process as they can be finalized only at the very end (+ sometimes very quick bugfix releases are needed).
Since they are later embedded in the app as changelog, limiting the number of languages also allows to limit the APK size.

The reason I think it doesn't worth the effort to translate the changelog is that it would need updates at each release while most people will probably never read it (many people already do not read the help, so let alone the changelog).

As a developer I use it occasionally, and I see it as a way to give in-app credit to people for their ideas and bug reports. However, I never had any feedback about this since the changelog is there (April) so I am thinking to someday maybe drop this changelog part altogether... (one more reason to not spend too much time on it)

@comradekingu
Copy link
Contributor Author

@falzonv The fastlane files themselves fall back to the default if translations are missing, maybe your setup could do that too?
I don't think it has to be in the app itself, but the F-Droid stuff is nice. They only show translations for the last version, for some reason I can't understand.

This nb_NO translation should work now though. Good to go I think.
If people don't read the help, the help doesn't qualify as help. I hope it got a lot better with the recent changes.
Least it should be better if they do read it.

@falzonv
Copy link
Owner

falzonv commented Aug 13, 2021

Regarding people not reading help or instructions, it was more a generic remark than specific to Discreet Launcher. There is even an acronym which has been invented due to this ("RTFM", which stands for "Read The F***ing Manual").


This nb_NO translation should work now though. Good to go I think.

This is also my opinion, thank you for this work!
Just before, there was one unanswered question where I would like your opinion:

To be honest I would still prefer to use simply "nb" for consistency with other languages being on 2 characters ("en", "fr" and "ru"). Is it really a problem for you to use "nb" instead of "nb-rNO"?

@comradekingu
Copy link
Contributor Author

comradekingu commented Aug 13, 2021

@falzonv
Unfortunately people stopped making good manuals 30 years go.
There will be yet other languages that use that convention for good/better reason. pt_BR and whatnot.
I have learnt to stop caring and assign blame to the ones making it so before my day.
Also, we are now set up for the world stage. nb_US is maybe relevant. Aspirations of spreading Norwegian has never been a thing though.

@falzonv
Copy link
Owner

falzonv commented Aug 13, 2021

Ok, thank you for your feedback.
Let's merge then!

@falzonv falzonv merged commit 27715ab into falzonv:main Aug 13, 2021
@falzonv
Copy link
Owner

falzonv commented Aug 13, 2021

I will also update issue #80 following the merge.

@falzonv
Copy link
Owner

falzonv commented Aug 13, 2021

Hum, I see it broke the build.
No problem, I will check and fix it when finalizing v4.7.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants