Chinese language style guide

Tags: #<Tag:0x00007f2a5a40afc0> #<Tag:0x00007f2a5a40a598>

Since there are more Chinese releases and artists now, I think it’s time for a Chinese language style guide to standardize formatting, names, etc. The current page is not very comprehensive and I don’t agree with some of it (we can discuss this). I don’t think we should draft a whole new guide and publish it at once, because it would take a long time and just stall the entire process. We should approach it piecemeal, so a new part can be added to the guide whenever we encounter problems or ambiguities during our editing routines.

This thread is to discuss what should be in the guideline, how it should be drafted, or even whether we should have a Chinese style guide, etc. All are welcome. I have taken the liberty of drafting my own guide on the wiki, which you are welcome to edit. I’m pinging active editors whom I’ve seen editing Chinese releases and works: @Sevenuno @jesus2099 @chikinov @dragonzeron @eggblink @dm4 @vermillon @alegrilli @fhm0096 @samddung

I’m starting this discussion because a lot of the guidelines are not suited for Chinese or Asian languages at the moment. For example, the default join phrase is " & ", whereas Chinese would just used a simple “、”. There are a lot of issues to discuss and it may get contentious, but I think we should implement what we agree on first.

3 Likes

I only edit on japanese albums

I have edited a few Chinese-language albums in the past.
I disagree with the passage in the Chinese language guideline forcing the use of foreign capitalization standards for words in those languages (e.g. if a release contains titles or partial titles in English, it’s required that we follow the English capitalization standards for those works). I would vote in favor of porting over the passage from the Japanese style guideline that says to use whatever capitalization is used on the packaging, in the interest of artist intent.

From what I’ve seen on Japanese releases, almost all Latin language on there are in capitals. Maybe labels do this to not worry about wrong capitalization? It seems almost excessive and I question if it’s the designer’s intent or the artist’s intent. Also, the Japanese guidelines do not say what capitalization rules should be used for packaging-independent entities like recordings and works.

There is a “consistency” requirement that helps narrow these cases down; in essence if more than one source (e.g. the artist’s website and the packaging) show the same capitalization, that is treated as the official capitalization. I wouldn’t oppose this for other East Asian languages as well.

In fact, about six years ago, a prototype Korean style guideline was posted on the old MB-style mailing list which included similar language to the existing Japanese guideline pertaining to Latin script capitalization. It got a few +1s IIRC.

1 Like

Thanks for the insight. How do you think conflicting official sources (e.g. record label website, artist’s personal website, Bandcamp run by artist) to be dealt with? Would it be any different now that alternative tracklists will be implemented in the future?

I usually give artwork priority, followed by any digital storefronts or artist/label websites, then finally retailers such as Amazon or Rakuten Books.

1 Like

That is mostly true with rock releases.
But pop releases do use capitalisation rather creatively and consistently as a part of the work title (and even for recording version names).

But for Chinese songs, I have not really felt such a strong requirement for keeping unusual capitalisations so often.
But my editing of Chinese is rather limited to a couple of artists.

@foolip could give advise also but you’re the best I know regarding Chinese and Chinese edit knowledge.

Thank you very much for enriching this guide so much, it will be so useful.

About a specific point:

Non-standard form characters 異體字

Due to the lack of character standardization, some Chinese characters could be written in several ways and are included in Unicode as different glyphs. Only standard characters should be used for official tracklists. For alternative “as-is” tracklists, any non-standard character should follow the character form printed on the release.

Don’t you think that a non standard character can be used on purpose and consistently by artist intent and therefore we should keep it in our main track list?

2 Likes

From the Hong Kong releases I’ve been working with, it’s hard to see purpose (e.g. that they have looked at characters A, B and C, and decided to use B). Most of the time, it’s which font they have chosen to use and how that font renders that character. This is especially true if the tracklist is handwritten by the cover art designer (which is not artist intent). Fonts are more standardized now with modern computers (after mid-1990s?), so these non-standard form characters are not as common as they were, say, in the 1960s–1980s. But of course, there will be artists who deliberately choose to use a non-standard character, which then we should follow artist intent.

I should also note that not all non-standard form characters are in Unicode, so this might be a problem.

1 Like
https://community.metabrainz.org/t/chinese-language-style-guide/426896
community.metabrainz.org
crawl=CC-MAIN-2019-30
30066
application/http; msgtype=response
sha1:C74OE4J35TYVHYNZCKGFXCIKLIYDTWQE
<urn:uuid:ec46ab21-f45a-4ba5-a805-177721973d49>
2019-07-21T11:41:17Z
104.197.202.120
text/html
sha1:5BSYPHBDFHXZHSX23RRKRXK5QWMML46A
<urn:uuid:59ba8e0f-1c4b-4c1e-aed8-dc769ea243d5>
https://community.metabrainz.org/t/chinese-language-style-guide/426896
response
<urn:uuid:65effb88-b20e-489e-a503-5748aa38c1fd>
isPartOf: CC-MAIN-2019-30
publisher: Common Crawl
description: Wide crawl of the web for July 2019
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-166-45-251.ec2.internal
software: Apache Nutch 1.15 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.1-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: http://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/