A few tweaks to translatable strings

[zlomzlom]

Turns out the &Edit text in the default_menu_platform.json file was being caught by the if ! grep -Fq "msgid $msgid" aegisub.pot; check in the make_pot.sh, which is why I was having a verb in the noun-only tab menu. For that reason I replaced the Latin d letter (U+0064) with visually similar Komi ԁ (U+0501; there also is a small Roman numeral 500 ⅾ (U+217E) in case something happens with the Komi De)

Additionally, I added a few contexts for buttons I was having some troubles with and moved the ampersand in the string Copy &to current script -> (it was Copy to &current script -> and was conflicting with the &Copy)

---

Originally, I tried making the DRAG_BIG_SQUAREs drawn in the visual_tool.cpp stop being visible all the time, but it became too much - I just wanna have a feature where only the selected lines in the subtitle grid will have their squares displayed. No luck with #379 too (I have to imagine someone else will be able to figure out both of these things in less than three seconds)

[arch1t3cht]

Replacing letters in strings with Unicode lookalikes just to avoid collisions is not a good idea; this creates problems with accessibility, for example.

What is the exact issue you were trying to solve with this? Which occurrences of &Edit need to be translated in different ways in other languages? Depending on the exact issue, this can probably be solved in some different way instead.

[zlomzlom]

It was way too long ago, so I've actually changed my mind about this PR

---

What is the exact issue you were trying to solve with this?

Well, my core problem is rather simple - there are multiple "&Edit" msgid instances in the POT file. "&Edit" located in "default_menu.json" doesn't have any explicit reference in the code, so it takes up msgstr value defined for buttons

Which occurrences of &Edit need to be translated in different ways in other languages?

I don't really know whether there's the same problem in other languages, but in my language menu tabs (File, Edit, Subtitle, etc.) must be translated as nouns (and all titles are already 100% nouns except for Edit). And when noun Edit translates as verb to Edit, it looks rather ugly

Depending on the exact issue, this can probably be solved in some different way instead.

I actually thought about it. Almost the next day I came up with an ugly hack - just change "&Edit" located in two buttons in files subs_edit_box.cpp and preferences.cpp to something like "E&dit", so Edit menu tab can be safely translated as a noun

I've spent countless hours to solve this issue, but in the end I don't think there's any other quickest and easiest solution

[arch1t3cht]

And when noun Edit translates as verb to Edit, it looks rather ugly

In which instances does Edit need to be used in the "to edit" sense in your language?

[zlomzlom]

Literally

[arch1t3cht]

So you'd like the &Edit string in the menu to have one context and the two strings in the style manager and hotkey menu to have a different (equal) context? That's what I was trying to understand.

In that case, the best solution is to make make_pot.sh set a context for the menu items. I can do this soon.

[zlomzlom]

Uh, I don't think that is feasible. I tried adding nmsgctxt specifically for Edit, though gettext won't recognize it (if that's what you meant in "context for the menu items")

[KerimDemirkaynak]

As far as I understand, while this seems like a very specific issue, similar noun/verb translation conflicts might easily occur for many other words across the dozen or so languages the project supports. Since I don't speak those languages, I can't say anything for certain, but my main point is this:

If we start going down the path of implementing custom workarounds for every single word, there will be no end to it.

[zlomzlom]

So, are you suggesting that we should stop making translations more flexible? I don't speak any other languages other either, but almost every person who submits a translation doesn't communicate or send any notes, context complaints, or suggestions, and it makes things... kinda awkward

I'm sure that other languages may have same issues, just like you said, but I don't think that, as of right now, any other thing needs a special workaround. And to create an additional context string, translators just need to add wxGETTEXT_IN_CONTEXT(...) in the code

By the way, I really hope this problem (and my translation too) will be resolved sooner rather than later. I think I have roughly two months before I won't be able to 100% guarantee stable access to the internet due to force majeure