osu-wiki
osu-wiki copied to clipboard
Add rule to ASC disallowing translation of section identifiers
i think it was @TicClick that was interested in doing this, the main idea is that links to sections become locale-agnostic (if article is up-to-date). also, it's consistent with how article filenames are used in links
some articles do this already but most don't. if this is merged, should look into adding a remark rule or something.
Just put my two-cents on this, I think it would be better to keep it how it is now. Translated section identifiers should be translated if the language doesn't borrow the word, i.e. "beatmap" tends to not get translated because it is unique to osu!. On the other end, if the translator(s) have a translation, then shouldn't it be translated for the sake of cohesivity?
it'd be a huge pain to copy custom english identifiers to every translation. if anything this should be automated in some way, perhaps with the url always using the corresponding english section for the identifier, and only using identifiers when sections don't align.
i assume the aim here is to always have the whole url in english, but wasn't the point of the english identifiers in some translations that the website links to some specific important sections (help centre etc.)?
Translated section identifiers should be translated if the language doesn't borrow the word, i.e. "beatmap" tends to not get translated because it is unique to osu!. On the other end, if the translator(s) have a translation, then shouldn't it be translated for the sake of cohesivity?
this is just about the url (the #fragment portion), not the actual headings that are visible in the article. i'm not sure what here relates to this.
I don't follow what the "huge pain" would be unless I'm missing some other consequence of this. there's no more work done in this way than we already do, it's just in a different place
currently, when making an FR translation for a link to /wiki/Beatmap#difficulty
, you have to go check /wiki/Beatmap/fr.md
, find the corresponding section yourself, and update the #difficulty
part of that link; (this is one of the more annoying parts of reviewing translations that prompted me to open this PR lol)
with new rule, the linking of corresponding sections would be done at writing/reviewing time of /wiki/Beatmap/fr.md
instead
perhaps with the url always using the corresponding english section for the identifier
my intention of this PR is to make "corresponding english section" an easy/obvious relationship to resolve (for both humans and computers)
i assume the aim here is to always have the whole url in english, but wasn't the point of the english identifiers in some translations that the website links to some specific important sections (help centre etc.)?
whole url in english makes sense to me but I don't think TicClick said anything about that. the existing matching IDs are to keep stable links across locales, this rule extends it as a requirement for the whole wiki. it's a problem whenever external links target sections of the wiki, and we can't know where that's happening
currently, when making an FR translation for a link to
/wiki/Beatmap#difficulty
, you have to go check/wiki/Beatmap/fr.md
, find the corresponding section yourself, and update the#difficulty
part of that link; (this is one of the more annoying parts of reviewing translations that prompted me to open this PR lol)
since when was this a thing? we haven't been doing this kind of thing in reviews as far as i know, and custom identifiers have only been used in special circumstances so far (shortening headings, consistent translation links for some important sections in the wiki)
i'm ofc not against having links be consistent, but having custom identifiers literally everywhere seems redundant
my reasoning for the Help centre changes is that those articles are 1) long and 2) important, and new links are less likely to break, as they are devoid of punctuation and not tied to the sections' titles. additionally, consistent identifiers make links without a locale more accessible, but again, that's all for external linking.
for me, it doesn't make sense to apply the same approach to the rest of the wiki -- that would force translators (and writers, too) to add something that isn't present in the original articles explicitly.
also,
currently, when making an FR translation for a link to /wiki/Beatmap#difficulty, you have to go check /wiki/Beatmap/fr.md, find the corresponding section yourself, and update the #difficulty part of that link
since when was this a thing? we haven't been doing this kind of thing in reviews as far as i know
truth be told, most of us (I got the feeling that "everyone except clayton") were skipping this part because it was really a pain in the ass and we didn't have any checks around that. shortly before they were added, we fixed a lot of broken direct links on the wiki.
I misunderstood the original conversation with @TicClick then, I didn't realise he only wanted this setup for Help Centre
I don't agree that it's more "important" there than anywhere else though -- the same problems can come up in any article, and it can all depend on how external links are pointing into the wiki, which we have no control over. to me it feels like the special treatment of Help Centre might come from bias in being more aware of how those articles are referenced externally than others
that would force translators (and writers, too) to add something that isn't present in the original articles explicitly.
that's true, I can imagine a lot of translators would not know to do this and so we'd have a lot of "fix section identifiers" kind of commits later. I'm not sure if that is something to worry about or not. as a reviewer I personally don't mind fixing for people (like said earlier, this would more or less be shifting the same work from some places to others)
I don't feel too strongly about this one overall but I would like to work toward less breakage of links pointing into the wiki. this is one possible way to help with that, and imo is a straightforward start
to me it feels like the special treatment of Help Centre might come from bias in being more aware of how those articles are referenced externally than others
likely yes
that's true, I can imagine a lot of translators would not know to do this and so we'd have a lot of "fix section identifiers" kind of commits later. I'm not sure if that is something to worry about or not
I'm strongly against that (at least as of now), as I prefer that all of us focus on meaningful work and ditch not-so-meaningful work. besides, if we use custom identifiers everywhere, that means adding them to English articles as well, which, in turn, will make us do double work (since that is already done automatically by the website) -- I really see that as redundant.
to sum it up: ok for some articles, not ok for the whole corpus
feel like I need some breakdown of why you guys are painting this like more work overall (e.g. "ditch not-so-meaningful work"), half of the reason I personally have any interest in this change is that it would make my work easier... it seems way more straightforward to have translations use the same identifiers as EN than for writers/reviewers of translations to cross-reference between EN and translated versions of every section link in that article (second paragraph of https://github.com/ppy/osu-wiki/pull/7638#issuecomment-1182835525)
besides, if we use custom identifiers everywhere, that means adding them to English articles as well, which, in turn, will make us do double work (since that is already done automatically by the website) -- I really see that as redundant.
I'm not sure if you meant it this way but just to be clear I don't think this should be done and it's not implied by this PR at all.
I think it's fine if you are only proposing to use English for existing identifiers, not all of them everywhere on every occasion, as I have initially thought (which is evident by my comments; perhaps I was too alarmist)
sooo uhh since everything is addressed, commented on and replied to, how about we just merge it?
assuming it is only about translations not overriding identifiers that are set explicitly
i see, that'd be ok but the wording still kinda doesn't reflect that, as i pointed out a while ago
Your translation may be missing new pending changes to English articles. Please update your translation after they are merged:
- https://github.com/ppy/osu-wiki/pull/9019, files:
Your translation may be missing new pending changes to English articles. Please update your translation after they are merged:
- https://github.com/ppy/osu-wiki/pull/9492, files:
Your translation may be missing new pending changes to English articles. Please update your translation after they are merged:
- https://github.com/ppy/osu-wiki/pull/9515, files:
Your translation may be missing new pending changes to English articles. Please update your translation after they are merged:
- https://github.com/ppy/osu-wiki/pull/9964, files:
From a translator's perspective, applying the existing custom identifier from an English section heading seems perfectly reasonable. Basically: Just copy the ID thing when translating.
Adding custom identifiers to section headings which don't have a custom identifier in English is a bit more work. It's feasible, but figuring out the section identifier of an English section heading could be a bit tricky (e.g. with punctuation), and I think including this as a PR requirement would increase the initial hurdle for new contributors.
I'm not sure how I would feel about such a rule. It'd add work, but not a ton. Is the benefit to having language-independent URL fragments big enough to warrant the extra work, though? I don't know.
Your translation may be missing new pending changes to English articles. Please update your translation after they are merged:
- https://github.com/ppy/osu-wiki/pull/10238, files:
closing this one because I haven't and probably still won't follow up with it for a while -- my opinion on the core goal of having section identifiers function similarly/identically to article directory names hasn't changed, but there's probably better means to get there. for a time where I'm more motivated to care about random technical improvements again.