it can work either way
we'd just need to set a standard and stick to it
we'd just need to set a standard and stick to it
Noffy wrote:
ok time for a re-review with slightly fresher eyes
the thing part thirty wrote:
Guest mappers, storyboarders, and hitsounders must be added to the tags of a beatmap set. This is to give credit where credit is due and helping others identify the main contributors of any given beatmap set.
-> + "Skinners should be added if they made the skin specifically for the mapset" (in contrast to someone just borrowing/mixing skin elements that're already out there) (this would be nice)
the thing part forty two wrote:
Commas, vs., &, any variations of feat./ft., CV: must always use a trailing whitespace. Unless it is a comma, leading whitespace is also required.
(CV: blah) vs. ( CV: blah ) . the latter would look silly, so CV: shouldn't require leading whitespace either. Or uhhh... this doesn't apply to sides which have the inside of a bracket next to them? or something. since it'd also apply to like, (feat.) vs. ( feat. ) which isn't.. better really.. hmmm
I'm not sure how to fix the wording for this though
aaaaaaaa~
Idea wrote:
Trailing/leading whitespace is not required if the character next to it is the inner side of a bracket.
Example: Hello (CV: Goodbye) is okay, Hello( CV: Goodbye ) is not.
I believe it should be moved to metadata. Conflicts shouldn't really happen if we're using a common sense approach, the few samples you had laid out earlier seem like they would work for most cases. It is just a much better way to handle determining cut songs vs full songs, unless the length is obvious from the listing as Noffy said.Lanturn wrote:
Anyways. TV Size time. So basically we'll just apply common sense for these and use whatever marker matches closest to our own preferences. Pretty much going back to our old school methods this way.
I mean we can work with that but it may cause some DQs when it comes to preference or conflicts down the line.
For me, I'd rather push towards something more concrete with the smallest room for error, which is moving them to the tags. I am fine with working with either method though.
So uh. Pick one I guess and we'll move along with it from there.
I wish not to fuel the fire of this longstanding debate which somehow has the resolution already. Yet, there is a flaw in this rule that I cannot resist to break my silence. It is not about 'v', 'yu', and 'yi', but that this rule does not take the existence of another language that adopts Chinese characters but whose pronunciation (and romanisation) are nothing like Mandarin Chinese into account. This language is Cantonese.Fycho wrote:
Glossary
Character-by-character Romanisation: Each Chinese character must be Romanised using Hanyu Pinyin system, and each romanised character must be capitalised and separated with a space.Rules
Songs with Chinese metadata must be Romanised using the Character-by-character method in Romanised fields when there is no Romanisation or translation information listed by a reputable source. The same applies to the Source field if a romanised Source is preferred by the mapper. As they are non-unicode fields, all diacritical tone marks must be omitted. Refer to Thread: Romanisation of Chinese for more information.
The discussion of "Romanisation of Chinese" should be adequate and stopped now. Anyone has concerns are free to contact me for detail explanations.
(This post is a continuation of my first post on page 12; the 179th post.)Wafu wrote:
@nold_1702: I don't really think that such a minority language (in osu!, it is a rarity in beatmaps) needs a specification. Simply because you then need to discuss whether Jyutping is the most appropriate to use. Although its Romanisation doesn't necessarily contain "characters with accents", it does contain numbers that define the accent, which is not understandable by anyone who doesn't know Jyutping specifically.
Fycho wrote:
We have agreed that “Cantonese metadata must be romanized as Cantonese pronunciation”. But we haven’t figured out which romanization way is better and should be used, so I didn’t add it to the proposal. Considering there are only less three ranked songs, we can stil apply a metadata discretion for them.
If you really want to discuss and figure out, also don’t forget Cantonese differs internally and has different tones in itself, I don’t know if forcing jyupin would be a solution and may have potentional issues with other cantonese speaker areas like Guangzhou. I am saying a metadata discretion by Mapper would be the best for them.
Okoratu wrote:
can someone translate Skylish's post into readable english for me? I've read it multiple times and dunno what he's trying to get at for half of it like the only sentence that makes sense is "I object a completely 100% Hanyu Pinyin forced on other Chinese languages excluding Mandarin under the PRC standardized Chinese." with reasoning "they're different enough to class as different languages"
nold_1702 wrote:
Wafu's Arguments
1. Cantonese is a minority language (on osu!). As such, we do not need to Romanise Cantonese.
2. To Romanise Cantonese the community needs to discuss which Jyutping is the most appropriate to use, therefore, in avoidance of this inconvenience, it is better for the community not to discuss.
3. The tones are to be taken into consideration, and it is troublesome. Thus, the community should not discuss it.
nold_1702 wrote:
Arguments (2) and (3) are also flawed in a way that they are not factually correct. For (2), Jyutping is the most widely used and the most authoritative. It is supported by a University dictionary and is the most accessible. Yales Cantonese Romanisation is also backed by Yales University, but it does not have an online dictionary and is not widely used at all. For (3), the tones in Mandarin are not taken into account when romanising, I see no reason one will be interested in the tones in the romanisation of Cantonese Jyutping.
nold_1702 wrote:
It is one thing not to Romanise Cantonese, but it is quite another thing to Romanise Cantonese in a wrong way by using a different language system to Romanise it. Perhaps I am not clear enough. What I mean is that in the old days, where the rule that presently concerns us was yet in existence, mappers had the liberty to use Jyutping to Romanise Cantonese titles. However, once this rule is passed, all Cantonese titles will be in need to be Romanised by using the Mandarin Pinyin system.
Okoratu wrote:
i think no one ever questioned that romanisation should be based on the language lol
shall i change the current wording to mandarin while we figure the rest out?
uh not too sure id agree on covers that just do same voice but if it's a drastically different song id say you should be following the artistMonstrata wrote:
Have a question regarding covers. I remember mentioning this to Eph but nothing was really concluded so maybe we can get some opinions here?
Currently metadata rules seem to suggest that if a song is covered by someone, that the entire metadata field should be taken from the cover's source. Example: https://osu.ppy.sh/s/658919 vs https://osu.ppy.sh/s/637445
If an artist is clearly covering or replicating another song, I think we should be taking metadata from the original song in cases where metadata is somehow different. After all, the melodies, rhythms, lyrics, etc... are all pretty much the same. It's the same song. Just sung by someone else. So shouldn't the only thing to change be the Artist/Romanized Artist field?
I'm actually not sure when this change happened because I remember at one point the practice was to just change the Artist and keep Title/Source the same as original song.
strongly agreeNatsu wrote:
It would be really annoying without the label, for example when you map the TV Size and the Full version the mapsets merge together, Also if you're looking for a normal length song you are going to get a bunch of tv sizes or viceversa... and being honest people rarely care about tags, so dropping in to tags isn't going to work.
Can you explain how it differs from "native users' daily practice"? Metadata = artist + title. Every language in osu! is (and always has been) using the same system for artists and titles (unless preferred Romanisation for one exists)pw384 wrote:
Sorry for disturbing, but I would like to confirm whether character-by-character method is also applied to the Romanization of Chinese artists name (if s/he hasn't provide an official Romanization). If so, I suggest mentioning it in the proposal as it differs from native users' daily practice, and may result in confusion if not specifically mentioned in ranking criteria. Like this: "Songs with metadata in Chinese, including both Artist and Title, must be Romanised in accordance with the Character-by-character method..."
Officially, native speakers never romanize their name via character-by-character method under any circumstance (e.g. 曹雪芹 is always romanized as Cao Xueqin in daily practice, instead of Cao Xue Qin or Cao Xue qin). So I am not sure whether the character-by-character method is applied to Artist name since it contradicts with our habits. If that is true, a specific clarification is better in wording in my opinion.Wafu wrote:
Can you explain how it differs from "native users' daily practice"? Metadata = artist + title. Every language in osu! is (and always has been) using the same system for artists and titles (unless preferred Romanisation for one exists)pw384 wrote:
Sorry for disturbing, but I would like to confirm whether character-by-character method is also applied to the Romanization of Chinese artists name (if s/he hasn't provide an official Romanization). If so, I suggest mentioning it in the proposal as it differs from native users' daily practice, and may result in confusion if not specifically mentioned in ranking criteria. Like this: "Songs with metadata in Chinese, including both Artist and Title, must be Romanised in accordance with the Character-by-character method..."
Pretty sure both ways of typing it out are fine (same with romanization = romanisation) though surely it'd be nice to use it consistently if that's what you meant with this ¯\_(ツ)_/¯Fycho wrote:
a minor stuff, For the consistency, romanize => romanise
Okoratu wrote:
Hi~
Noffy, Lanturn and I sat down and got this worked out as a draft implementing all the above points.
The draft as a whole is available over there: https://gist.github.com/Okorin/c551fd4263e437e0ffcbd3f51ffb2736
if nothing else is brought up i'll PR this in a week ok
thank
Songs with German metadata must romanise umlauts into two-letter equivalents (ue, oe, ae and ss).Is this supposed to contain the nordic equivalents of these too? As well as the additional Ø Æ Å and whatever there are, how's the deal with them?
Okay so first of all I ain't really expert, but maybe some of this might prove useful.Okoratu wrote:
you are a nordic person you should know what deal those are better than i do
i just added the things i knew about languages to that draft
provide me knowledge if it's relevant and i'll add