Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDescription for issues.ref_closing_from ambiguous and incorrectly localized #13123
Comments
solution: fix template to: add a check if time is in the past ... if true, use new translation strings <- has to be added |
The date will always be in the past because it references the date when the pull request was added. |
oh missed that ... then it's easy: fix the english translation by creating a pull and the rest is done via crowdin |
Rather than changing the ordering of the words, I think a good solution would be maybe adding a hyphen before the time of reference. i.e.
But then, this will mean that many actions that have the time reference at the end would need an update, not just the reference to the pull request. Does this sound like something feasible? I can do the PR to address this. Just want to know this sounds like the correct decision (cc. @6543) |
I think adding an em-dash — (U+2014) (not hyphen) would be a good idea |
I've been thinking the same thing as @ivanvc. The English version is ambiguous, yes, but not a bad wording per se. Visually setting off the date string rather than incorporating it into the sentence looks to me like a good way to resolve the ambiguity and also make sure that date strings can be at the end of the message in all languages alike. I have also suggested a correction of the faulty German translation on Crowdin, which still needs to be reviewed there. Let's see how quick they are. ;) |
True, if we only change it for this message. |
That was what I initially was doing, changing it from all the event texts. However, I noticed that it looked somewhat incosistent with the text from the section headers. I guess there are two improvements here. One is to standardize the style across those texts, and another is to add the dash to the localization files. |
In most cases as in „added 2 commits 22 hours ago“ the timestamp at the end of the sentence looks good and is sementically correct. It works well in English, whereas e.g. in German the timestamp always comes before the participle. The ambiguity in English for this specific case might just be kept. If one has understood the message once, one will most likely not misread on further occurences. Also I did not intent to start a general discussion about wording and structure. My initial report was just to confirm I understood the meaning correctly, and that the German translation should be fixed. @eneuschild Is there an accessible link on Crowdin to the proposed German translation? I did not post my translation in this issue yet and would just move the timestamp after the main verb:
|
@qwertfisch The link is https://crowdin.com/translate/gitea/68/enus-de?filter=basic&value=0#74642, but it requires login. My suggestion on crowdin was to move the timestamp to the end:
Now that I look at it in a proper sentence, that looks terrible. Your way is clearly better for German, but there's still the timestamp-at-the-end consistency issue. I'm unsure which way to go. |
As I said previously, the timestamp is in many German translations already not at the end, because of the language itself. I see no reason why to start with awkwardly sounding sentences now. Would you change your suggestion on Crowdin or how does this work? |
Yes, I agree. Done. |
[x]
):Description
After a pull request is added by a user and linked to an issue, the following reference is then described in the given format:
A specific example would be:
Ways of reading
This is quite ambiguous. Even more so in German, which clearly is translated unambiguously by the second form (considering the position of the comma and the date inside the subordinate clause).
Unfortunately English does not enforce commas and also puts the date at the end of the sentence.
Screenshots
Possible solution
I am not sure if this is a definitive bug or just an ambiguous way of reading (for English). At least the German translation should be changed to not represent the second form semantically.
An umambiguous reading could be something like this:
This way only the part “has referenced a pull request” can be an href link, not the text “that will close this issue” after the date. This behaviour is already present at the incorrect German translation, where “schließen wird” (after the date) is just text, not an href.