-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Deduplicate frequent translation strings #29823
Conversation
@@ -9,7 +9,7 @@ | |||
</a> | |||
{{end}} | |||
<a class="{{if .PageIsExploreOrganizations}}active {{end}}item" href="{{AppSubUrl}}/explore/organizations"> | |||
{{svg "octicon-organization"}} {{ctx.Locale.Tr "explore.organizations"}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a personal viewpoint (#29816): Oh no, a merge conflict 🥲
@@ -1281,7 +1246,6 @@ editor.file_delete_success = File "%s" has been deleted. | |||
editor.name_your_file = Name your file… | |||
editor.filename_help = Add a directory by typing its name followed by a slash ('/'). Remove a directory by typing backspace at the beginning of the input field. | |||
editor.or = or | |||
editor.cancel_lower = Cancel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did a lower
ever end up in the translations?
And why isn't it even lowercased?
But that will make it untranslatable correctly and that defeats the whole point of translating. It would be the same as proposing to replace all occurrences in English language for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Blocking for now as this really needs to be reviewed more from the point of other languages
But if we really want to make it correct from every grammatical point, we would need a new translation key for every scope where it is used. We have private in the context of users, orgs, repos, projects, email addresses, members.... we simply cannot maintain an own translation for every single one of these things. What would be the alternative? We cannot give a word a gender (that's the issue if I understand correctly) because it changes depending on the language. Does Latvian for example really not contain a way to express this state neutrally? In Ukrainian or Russian there's the same problem, but you can avoid it by using an adverb instead of the adjective. Yes it sounds weird, but you can get used to it. Alternatively you can translate with braces like |
I totally agree to dedupe down to one value. It will definitely be a good enough translation still. If by chance one of the reviewer notices a case where context helps, we can keep these and mark the dupe ones with a comment. But we can't possible know all these cases in advance and there is already some "sharing" going on as well. |
I will add some basic "linting" capabilities to the script in #29825 which will be a good validation to run this PR against to detect unused or missing translations. |
Latvian language does not have neutral way of expressing such cases and while it would be possible to write |
On a scale of 1 (nit) to 10 (meaning gets lost), how bad is the error? Certain minor issues have to be accepted imho. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then please propose a solution |
Imho adjectives most probably cannot be deduplicated to keep context, also cannot deduplicate where one is verb (action), other noun (label) even if both in English are written the same |
I agree with the second one, but we cannot create a new adjective translation for every case where it is used. If they exist currently, it's mostly just by accident |
Compromise for now - I revert the commits for everything that is used as adjective/verb, we can at least merge the non-confusing nouns, and then we think of a solution for the other ones |
@@ -23,7 +23,7 @@ func (o OwnerType) LocaleString(locale translation.Locale) string { | |||
case OwnerTypeRepository: | |||
return locale.TrString("concept_code_repository") | |||
case OwnerTypeOrganization: | |||
return locale.TrString("concept_user_organization") | |||
return locale.TrString("organization") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why I used concept_user_organization
here, the reason is the same as the previous discussion: I believe we should clearly define the concepts with context. I think "organization" could have different means in different contexts in different languages.
- One context, one concept, one translation.
- Different context, different concept, different translation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I increasingly think we need to restructure translations completely. Not group them by usage (new issue page, admin user table, installation page) but by context or meaning ([permissions]
, [operations]
, [repo_units]
and so on)
I still think there are unclear concepts. For example: "dashboard". I can see in Chinese translation, it was translated to "Home page". It is right in Chinese when the "dashboard" is used in the home page context. But it is wrong when it is used in the admin pages. But this PR "deduplicates" them .... it leads to wrong result. To answer the question "Then please propose a solution": My opinion is: "only take actions when it matches at least one of these conditions":
My understanding about how to make the translations correct:
For this PR's change, I think it doesn't aim to resolve bugs, and we haven't got a full picture of all language translations. |
@go-gitea/technical-oversight-committee I think we need an opinion from the TOC here |
Imho some people just need to go through the modifications in the ini and highlight the cases where deduplication is not possible and then we split those up again. Just a normal review process imho. Just saying "no" to the entire PR is not constructive feedback. |
I'd like to, but I only understand English and Chinese, and I have shown the real problem (eg: "dashboard"). So I can't comment for other languages. Actually I would prefer to insist my suggestion in #29823 (comment) . |
We may need wider feedback on this, or to take inspiration from other projects. Do any of our translators have a suggestion on the matter, how it could be made easier? Would weblate make this easier or harder? Glad this PR sparked the conversation, but we'll want to make sure we have an agreed solution before we merge. |
As title. Cases where we get fancy with constructing the string are excluded for now, as are most strings which contain more detail, e. g. "Edit" is included but "Edit File" is not.
Per commit, only one string or few less frequent strings are changed to simplify review.
Part of #27700 , #24488