search

tenacityteam / tenacity-legacy

THIS REPO IS NOT MAINTAINED ANYMORE. Please see https://codeberg.org/tenacityteam/tenacity for Tenacity, which is maintained.
https://tenacityaudio.org
Other
6.77k stars 257 forks source link

Program still says "Audacity" and has no translations when ran from build dir #575

Open JPcode05 opened 3 years ago

JPcode05 commented 3 years ago

Guidelines

Version/Commit hash

a1cfcce

Describe the bug.

In the titlebar of the program, it still says "Audacity". When you open the Help menu in the menu bar, it also says "About Audacity..." even though I couldn't get that in my screenshot.

However, when I click "About Audacity..." it does correctly show "About Tenacity" so we can about that.

Expected behavior

The titlebar needs to say "Tenacity" and the Help menu is supposed to say "About Tenacity..." not Audacity.

OS

Arch Linux

Additional context

Screenshot_20210903_105543

P.S. This is the first time I'm running Tenacity! I'll make a YouTube video about it soon...

This issue is not a duplicate

leio commented 3 years ago

Please show the output of the locale command

JPcode05 commented 3 years ago

Please show the output of the locale command

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
leio commented 3 years ago

This is happening because you are running from the source tree, and those strings are still all "Audacity" inside the code. Because you aren't running it from a full install (but from inside the build dir), gettext doesn't see the translation catalogs, and thus doesn't apply the hack where the strings all get changed from Audacity to Tenacity as part of en.po english translation.

This kind of approach to renaming is problematic and would be completely shot down in communities with many projects and translation teams handling them (as would touching translation files by developers instead of the language team, even for such renames and adapting to source code changes), but I can see why this was done here to reduce the delta with audacity.

Before I thought I would always see it as Audacity, because my locale doesn't have a translation, but apparently it's somehow picking up English translation then afterall, instead of using the original strings as I expect to happen. Maybe this was thought about and somewhat hacked around already to do this in this situations.

If it were up to me, I would stop hacking around like this and change the original strings instead, but I'm not the one willing to do merge/cherry-picking work from audacity changes, so that's that.

n0toose commented 3 years ago

If it were up to me, I would stop hacking around like this and change the original strings instead

I think me and @emabrey talked about this, but the problem was that we'd lose many translations unnecessarily. I'm not sure if we should just go for it, we do have a couple of fairly dedicated translators.

leio commented 3 years ago

If it were up to me, I would stop hacking around like this and change the original strings instead

I think me and @emabrey talked about this, but the problem was that we'd lose many translations unnecessarily. I'm not sure if we should just go for it, we do have a couple of fairly dedicated translators.

Well, the translations were already edited to change Audacity to Tenacity in the translations without translator involvement (something that would be frowned upon in my usual GNOME circles, as I said, but the situations are different here). I figured that it was done like this to ease merging changes from Audacity. But otherwise it's "just" a matter of changing the original string as well in the PO files along with the source code change (msgid too, as opposed to just the msgstr as was already done), and then we can drop en.po until this gets revisited for key approach with fluent or whatever else in the future.

My main arguments for doing the string changes in source code are:

If we go towards the DarkAudacity kind of hack in TranslatableStrings, then mind the last point; I guess in that case the places where it has to actually stay Audacity need to be moved out of the translatable string, via %s and putting it in as a variable that comes from a string that is NOT marked translatable, perhaps.

emabrey commented 3 years ago

If it were up to me, I would stop hacking around like this and change the original strings instead

I think me and @emabrey talked about this, but the problem was that we'd lose many translations unnecessarily. I'm not sure if we should just go for it, we do have a couple of fairly dedicated translators.

Well, the translations were already edited to change Audacity to Tenacity in the translations without translator involvement (something that would be frowned upon in my usual GNOME circles, as I said, but the situations are different here). I figured that it was done like this to ease merging changes from Audacity. But otherwise it's "just" a matter of changing the original string as well in the PO files along with the source code change (msgid too, as opposed to just the msgstr as was already done), and then we can drop en.po until this gets revisited for key approach with fluent or whatever else in the future.

My main arguments for doing the string changes in source code are:

* The translations don't apply when there's no translation file there, so if you run it out of build tree or don't have an en.mo or whatever other reason, you will still see Audacity instead of Tenacity (as per this bug report)

* When this happens, maybe there are trademark concerns

* gettext is meant to be used with an original language in source code and most translators are familiar with that kind of workflow (I mean translators that work on translating many FOSS projects for their language), and all their setup is geared towards that (e.g. translation memory in things like poEdit), with no experience with something going through weblate that mangles the PO file to work off of english translation for the source strings or whatnot

* Clarity where it should be Tenacity, and where it actually needs to stay as Audacity for correct attribution (about dialog stuff)

If we go towards the DarkAudacity kind of hack in TranslatableStrings, then mind the last point; I guess in that case the places where it has to actually stay Audacity need to be moved out of the translatable string, via %s and putting it in as a variable that comes from a string that is NOT marked translatable, perhaps.

Random people's issues aren't the place to have a long post about what you prefer the gettext setup to be. Please do that in IRC/Matrix or make a separate issue.

leio commented 3 years ago

The appropriate issue IS the place to do this, not a chat medium with no contextual history. This is discussion about which way to solve the issue reported here, if at all, hence precisely the appropriate issue and place. Also this was already a summary of previous discussions, to actually get to a decision, not chat and chat in IRC with no conclusion on record. Also I wouldn't call JPcode05/jamesp, or anyone else for that matter, as "random people".

emabrey commented 3 years ago

The reason it is like this has nothing to do with gettext. It has to do with the fact that whomever added changes to AudacityApp::onInit() didn't make sure that all the different OSes have consistent behavior for populating the search path.

I didn't call them random people, I said that the issue you chose to talk about this on was a random person's (which isn't the same thing). The thing which I described as random was the issue that you chose, not the person.

You are very argumentative and I don't intend to argue with you about this. Please do not hijack this unrelated issue.