Gadgetbridge app name for Nightly/Nopebble builds only changes for default US locale

gfwilliams commented

2022-03-31 08:20:00 +00:00

Member

Before reporting a bug, please confirm the following:

I have read the wiki, and I didn't find a solution to my problem / an answer to my question.
I have searched the issues, and I didn't find a solution to my problem / an answer to my question.
If you upload an image or other content, please make sure you have read and understood the Codeberg Terms of Use

I got Gadgetbridge from:

F-Droid
I built it myself from source code (specify tag / commit)
I previously used Gadgetbridge from other sources and then updated to F-Droid version

Your issue is:

Nightly, Nopebble (and soon Bangle.js) builds are all just called 'Gadgetbridge' in most locales outside the USA, but in the USA they are named correctly.

These non-default builds have a customised app_name in app/src/BUILD_TARGET/res/values/strings.xml so as not to be confused with each other. However, in pretty much all non-US languages, the language translations in app/src/main/res/values-LANG/strings.xml take precedence.

Most translations include <string name="app_name">Gadgetbridge</string> even though this is not a translation, it's just the default value for app_name. It applies for other things too like the main activity name.

More info in #2621

Fixes

We could remove all app_name=Gadgetbridge entries in the translations, and then add app/src/BUILD_TARGET/res/values-LANG/strings.xml for app_name in the few (5?) cases where there actually was a translation.
We could just add app/src/BUILD_TARGET/res/values-LANG/strings.xml for every language - more duplication, but this then doesn't have any effect at all on the normal build
remove the translations
add a new string app_name_build_variant and set the app_name via code from this variant - thus allowing the name to be localized

... others?

Your wearable device is:

Bangle.js

#### Before reporting a bug, please confirm the following: - [x] I have read the [wiki](https://codeberg.org/Freeyourgadget/Gadgetbridge/wiki), and I didn't find a solution to my problem / an answer to my question. - [x] I have searched the [issues](https://codeberg.org/Freeyourgadget/Gadgetbridge/issues), and I didn't find a solution to my problem / an answer to my question. - [x] If you upload an image or other content, please make sure you have read and understood the [Codeberg Terms of Use](https://codeberg.org/codeberg/org/src/branch/master/TermsOfUse.md) ### I got Gadgetbridge from: * [x] F-Droid * [x] I built it myself from source code (specify tag / commit) * [ ] I previously used Gadgetbridge from other sources and then updated to F-Droid version #### Your issue is: Nightly, Nopebble (and soon Bangle.js) builds are all just called 'Gadgetbridge' in most locales outside the USA, but in the USA they are named correctly. These non-default builds have a customised `app_name` in `app/src/BUILD_TARGET/res/values/strings.xml` so as not to be confused with each other. However, in pretty much all non-US languages, the language translations in `app/src/main/res/values-LANG/strings.xml` take precedence. Most translations include `<string name="app_name">Gadgetbridge</string>` even though this is not a translation, it's just the default value for app_name. It applies for other things too like the main activity name. More info in https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2621 #### Fixes * We could remove all `app_name=Gadgetbridge` entries in the translations, and then add `app/src/BUILD_TARGET/res/values-LANG/strings.xml` for app_name in the few (5?) cases where there actually was a translation. * We could just add `app/src/BUILD_TARGET/res/values-LANG/strings.xml` for every language - more duplication, but this then doesn't have any effect at all on the normal build * remove the translations * add a new string app_name_build_variant and set the app_name via code from this variant - thus allowing the name to be localized ... others? #### Your wearable device is: Bangle.js

vanous commented

2022-04-02 14:53:05 +00:00

Owner

This is my first shot at this @gfwilliams , @ashimokawa . I did actually not try to localize the names yet and i did not remove unused files etc...

https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/TranslatableVariants

This is my first shot at this @gfwilliams , @ashimokawa . I did actually not try to localize the names yet and i did not remove unused files etc... https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/TranslatableVariants

vanous commented

2022-04-03 10:17:42 +00:00

Owner

OK, my latest version should work as expected - the app name is modified in manifest (via gradle variables) and then in all other occurences (via code). This means that launcher and all android dialogs have correct name.

I have not tried translations yet but it should work.

One current limitation:

If one builds a "banglejs" product flavor with "nopebble" build type (i presume this would only happen during debug but not for any production release), then the "nopebble" takes priority. This could likely by solved by adding a nopebble build type to the banglejs variant :) (This is because the string replacement via code is a bit more flexible, while in gradle, one must define the matrix combinations).

OK, my latest version should work as expected - the app name is modified in manifest (via gradle variables) and then in all other occurences (via code). This means that launcher and all android dialogs have correct name. I have not tried translations yet but it ***should*** work. One current limitation: If one builds a "banglejs" product flavor with "nopebble" build type (i presume this would only happen during debug but not for any production release), then the "nopebble" takes priority. This could likely by solved by adding a nopebble build type to the banglejs variant :) (This is because the string replacement via code is a bit more flexible, while in gradle, one must define the matrix combinations).

gfwilliams commented

2022-04-04 10:07:34 +00:00

Author

Member

Thanks! Looks good to me...

edit: I'm not too concerned about the "banglejs"/"nopebble" thing. Not sure, but does it even make sense to make "nopebble" a build flavor instead of build target now?

Thanks! Looks good to me... edit: I'm not too concerned about the "banglejs"/"nopebble" thing. Not sure, but does it even make sense to make "nopebble" a build flavor instead of build target now?

vanous commented

2022-04-04 14:25:21 +00:00

Owner

I think that we should rename the pebble provider by default in the Bangle.js Gadgebridge. If not, the Bangle.js Gadgetbridge will silently fail to install on mobile devices where either Gadgetbridge or Pebble app is installed - which given the demographics, can be some percentage of the user base.

One more comment: most likely what i do via code can be done via gradle, thus we could perhsps remove the java code. This would be better (less room for error) but a bit harder to grasp (one is using string resources which actually do not exist.) And, a bit of special syntax in the xml is required: tools:replace="android:label" must be added.

I am not 100% sure about the possibility to remove the code because this often behaves in very unpredictable way and i did not test it. Right now, it is working as is :)

I think that we should rename the pebble provider by default in the Bangle.js Gadgebridge. If not, the Bangle.js Gadgetbridge will silently fail to install on mobile devices where either Gadgetbridge or Pebble app is installed - which given the demographics, can be some percentage of the user base. One more comment: **most likely** what i do via code can be done via gradle, thus we could perhsps remove the java code. This would be better (less room for error) but a bit harder to grasp (one is using string resources which actually do not exist.) And, a bit of special syntax in the xml is required: `tools:replace="android:label"` must be added. I am not 100% sure about the possibility to remove the code because this often behaves in very unpredictable way and i did not test it. Right now, it is working as is :)

gfwilliams commented

2022-04-20 12:37:35 +00:00

Author

Member

What does everyone think about this? I'm happy with whatever, but I'd quite like to get this (or another solution) merged :)

vanous commented

2022-04-21 21:00:13 +00:00

Owner

I would love to try the "no code" solution but I have been deeply consumed by dayjob... and will be for at least another 14 days. We can merge this for now and look at different ways later too. I will look at it tomorrow, at least to rebase and merge.

vanous commented

2022-04-23 05:35:07 +00:00

Owner

What does everyone think about this? I'm happy with whatever, but I'd quite like to get this (or another solution) merged :)

Here is a new branch partially based on my previous test and trials, which should do exactly what we need but all the definitions are now in gradle, no extra java code, thus eliminating potential bugs.

https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/TranslatableVariantsWithoutCode

@gfwilliams can you please test if this is still working for you and provides a solution to this issue? Thank you!

> What does everyone think about this? I'm happy with whatever, but I'd quite like to get this (or another solution) merged :) Here is a new branch partially based on my previous test and trials, which should do exactly what we need but all the definitions are now in gradle, no extra java code, thus eliminating potential bugs. https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/TranslatableVariantsWithoutCode @gfwilliams can you please test if this is still working for you and provides a solution to this issue? Thank you!

gfwilliams referenced this issue from a commit

2022-04-26 14:29:43 +00:00

Update strings for app_name/etc to '_generic' values to allow differently named apps - https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/2627

gfwilliams commented

2022-04-26 14:32:22 +00:00

Author

Member

Thanks!

I just tried this and the app is still just called Gadgetbridge for the British translation. While you had removed the line <string name="app_name">Gadgetbridge</string> from strings.xml, it's still defined in all the translations so I guess those overwrite everything (same deal as before)?

However, if I replace "app_name"/etc with "..._generic" in all the translations it's all good. Hope you don't mind but I just pushed the changes to https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/TranslatableVariantsWithoutCode to save some trouble

I'm pretty happy with that as a solution if you are?

Thanks! I just tried this and the app is still just called `Gadgetbridge` for the British translation. While you had removed the line ` <string name="app_name">Gadgetbridge</string>` from `strings.xml`, it's still defined in all the translations so I guess those overwrite everything (same deal as before)? However, if I replace `"app_name"`/etc with `"..._generic"` in all the translations it's all good. Hope you don't mind but I just pushed the changes to https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/TranslatableVariantsWithoutCode to save some trouble I'm pretty happy with that as a solution if you are?

vanous referenced this issue from a commit

2022-05-01 12:26:46 +00:00

Update strings for app_name/etc to '_generic' values to allow differently named apps - https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/2627

vanous commented

2022-05-01 12:38:55 +00:00

Owner

@gfwilliams thank you! Sorry for the delay. It is now merged into master. I have again tried different variations and the solution with code had a tiny bit more flexibility but i think what we now have is good. Please still try with our configuration and different language settings on your phone, on my devices this seems OK.