Make even more strings translatable and fix some others

[zlomzlom]

I think right now everything is translatable except for Lua stuff and logging (and I still don't know how to squash, sorry)

[arch1t3cht]

Generally the solution to translatable strings in different contexts having the same string is not to subtly change one of them, but to add a context to the translation. Then, instead of _("Open Audio File") you can use wxGETTEXT_IN_CONTEXT("Open Audio File", "dialog"), for example.

[zlomzlom]

Yeah, but every other string in file selectors already isn't capitalized (like in "Save audio clip", "Open keyframes file", "Open subtitles file", etc.)

[zlomzlom]

I don't know what I should do. Do I replace every non-capitalized string just like you said (wxGETTEXT_IN_CONTEXT("Open Audio File", "dialog")), or?..

[arch1t3cht]

I'll make the changes I need and squash the commits and push to your branch soon, like last time.

[arch1t3cht]

Done; will merge tomorrow if the CI goes through.

[zlomzlom]

Nice, thank you for bearing with me. I also wanted to ask some questions (and probably make my final contribution, if it is possible):

1. How come throwing an exception generates a dialog window? I tried searching around in the code and in the wxWidgets documentation, but didn't find anything meaningful;
2. Is there any smart and feasible way of making logging and exception dialogs translatable too? I was experimenting with exceptions in the meantime by replacing std::strings with wxString instead in libaegisub/include/libaegisub/exception.h and tried to make some strings translatable through the _() macro (although I wish there was a fast way to debug every exception, because I don't know which exceptions should be displayable and which not);
3. While looking into exporting subtitltes, I noticed that some subtitle formats ("EBU subtitling data exchange format (EBU tech 3264, 1991)", "MPEG-4 Streaming Text", "Plain-Text") could be translatable as well. I kinda didn't manage to succeed, because you can't overload from_wx() function to handle str::string_view due to the second wxString argument (on second thought, prolly the most sane thing is just to use std::string_view(_("Plain-Text").utf8_str()) maybe?)

[0tkl]

@zlomzlom I don't have permission to write this PR directly, so I opened a PR in your repository. Dividing it into 4 commits is just for easier browsing; I recommend squashing when merging.

@arch1t3cht #482 and this PR brought about too many petty changes to the original text, especially those that did not change or barely changed the translation. Since you put the “Regenerate pot file” commit in this PR, I suggest putting the regeneration and manual intervention to po files here as well.

[zlomzlom]

First of all, I deliberately don't add po files while regenerating pot, because there are three translation requests hanging around (two of them seem abandoned, though (and any other translator can manually update their language's po file from pot and patch up fuzzy strings if there are any))

And I've already told two times, I don't know how to squash commits and I have no idea what will happen when I accept your pull request

[arch1t3cht]

How come throwing an exception generates a dialog window?

Exceptions are caught somewhere in some Aegisub component and displayed as a dialog there, or, if they propagate all the way upwards, caught by wxWidgets and passed to AegisubApp::OnUnhandledException in main.cpp where they are then displayed as a dialog.

Is there any smart and feasible way of making logging and exception dialogs translatable too?

I don't think translating log messages is a good idea (at least without any further handling), since logs are mainly used as debug info to be passed onto developers when reporting bugs, and translating the logs would just complicate this. If logs are made translatable, they'd need some sort of special handling where every log message is a translatable format string that's translated in the log window but not translated in log files, but that'd need a big refactor.

Translating exceptions is also hard in general. We can translate the exceptions that Aegisub itself generates, and addressing #379 might help translate some of wxWidgets's exceptions, but exceptions from other libraries like ffms2 cannot be easily translated. But, similarly to log messages, I also don't think they should be: Exceptions are only supposed to be interesting to developers. If there are situations where an exception contains necessary information for the user that's only visible in the exception message, then that should instead be solved by catching the exception and adding a more user-friendly translatable error message in Aegisub.

because you can't overload from_wx() function to handle str::string_view

This I cannot answer immediately, I'll look into this when I can.

add some ad-hoc code (which I didn't push into this branch) so that at runtime, it automatically preserves the translation for some original texts that only involve case changes, such as from "Open video file" to "Open Video File".

I don't think this is the best solution here. First of all, I agree with @.zlomzlom that po files should not be regenerated every time the pot file is updated since this only complicates in-progress translation PRs with no real gain (when fuzzy matching is disabled).

Ideally the po files should be updated to match the small fixes to some strings, yes, but doing this automatically is not ideal. It's quite possible that the various languages will also need to make fixes to the capitalization, for example.

gettext already has features to handle this - this is what fuzzy matching is for. This will mark the strings as needing human review in the po file and keep the previous msgid around for comparison. The correct solution here is to split the added strings and the changes to strings into separate pot file updates and then msgmerge the changes into the po files with fuzzy matching enabled. I will do this soon.

[zlomzlom]

I don't think translating log messages is a good idea

Okay, I see

Exceptions are only supposed to be interesting to developers.

But some of them are still displayed to the users (I mean the Aegisub ones, which are describing the errors). I myself definitely encountered a few, however, I don't remember which exactly

[KerimDemirkaynak]

But some of them are still displayed to the users (I mean the Aegisub ones, which are describing the errors). I myself definitely encountered a few, however, I don't remember which exactly

Translating something that appears so infrequently might not be worth the effort/time on your part.

[zlomzlom]

You might be right... I've already spent hours on marking strings for translating

[0tkl]

zlomzlom: I deliberately don't add po files while regenerating pot, because there are three translation requests hanging around
arch1t3cht: I agree with @.zlomzlom that po files should not be regenerated every time the pot file is updated since this only complicates in-progress translation PRs with no real gain (when fuzzy matching is disabled).

I will skip Russian since you zlom is actively working on #344 . I will postpone applying the changes to Korean for the time being to await Hackjjang's response. I will apply the changes to Chinese (China), as I will eventually have to decide whether to address or abandon that severely deviating PR.

zlomzlom: I don't know how to squash your commits

While squashing your own commits on the web isn't convenient, you can indeed squash other's commits from PRs pushed to you on the web:

arch1t3cht: The correct solution here is to split the added strings and the changes to strings into separate pot file updates…

Seconded. I'll close the PR on the zlom side as soon as you're ready.

[zlomzlom]

Alright, just to clarify: I don't need to do anything else on my end (like merging 0tkl's pull request)?

[arch1t3cht]

No, that's fine, I'll handle this myself.

[zlomzlom]

Okay, thank you again

[arch1t3cht]

Pushed now. Will merge in a bit unless there are more complaints.