Template talk:Type Code
I guess we ought to have a uniform way to list creator codes, in addition to type codes. We could add a parameter to this template (pretty easy), or add a parameter to the FormatInfo template (harder, at least for me). Or, since the FormatInfo param is basically free-form, we could make no template changes, and just decide on a way to write it that supports creator codes.
Is there a standard way to write the combination of a creator and type code, in the Mac world? Like "CCCC::TTTT", or "c=CCCC/t=TTTT"? How should we deal with the presumably common situation where an article covers formats with a single creator code, but multiple type codes that go with it? Jsummers (talk) 15:57, 9 May 2019 (UTC)
Type codes should be interchangeable with the way extensions are displayed. Creator codes are a different beast, a file format might have been created with different programs, with just an extension we are not sure which program created them, but if we still have the creator code we will. This article explains it better: CultofMac.
As far as writing them together, I have always seen them referred to as "Type/Creator". Maybe we could only include the different "Types" in the FormatInfo and then keep a separate list of Creator codes which link to format pages? I think the benefit would be greatest by having all these codes in one place so when someone comes across a file with no extension but can see the Type/Creator codes, they can identify them through a search. --Thorsted (talk) 18:06, 9 May 2019 (UTC)
"The Type/Creator name is 8 ASCII characters: the first 4 are the type, the second 4 the creator. " The Programmers Apple Mac Sourcebook page 80 notes --Thorsted (talk) 18:11, 9 May 2019 (UTC)
- It would be nice if type codes always corresponded to file types, and yes it should have been that way. But, for example, the type code for BinHex format is TEXT, which is useless, because TEXT is the type code for plain text. If you want to know what type of file it is, you unfortunately have to take the creator code BNHQ into account. Writing something like "Type code:
TEXTBNHQ" seems fine to me, but I don't know whether it makes sense to Mac users. Jsummers (talk) 18:44, 9 May 2019 (UTC)
- It seems to me like absolute positions on whether or not creator codes should be listed, "not at all" and "always, in the infobox", both have dislikable consequences:
- If they are not listed, there will be situations where (as Jsummers mentioned) a single type code refers to multiple formats, with no way to tell which one a file is besides looking at its contents.
- If they are listed, many, especially those of widespread formats, will end up listing a very large number of type/creator combinations, and probably with many more that are not listed. This also seems like it may (depending on how thorough you wants to be) consume a lot of time when writing a format page.
- Assuming that neither of these two are desirable, what I think are the remaining options are:
- To list the creator codes on a separate page, as Thorsted suggested. (I dislike this one because it seems to break the ability of format pages to "stand on their own"; perhaps I'm somewhat hypocritical in thinking that this is the case to begin with, though - my own most recent format page consisted of almost nothing but "see another page".)
- To list the creator codes in the infobox only whenever this is useful for disambiguation.
- To list the creator codes (along with the type codes?) in the page body, in a way similar to magic numbers. (This is my favorite, because it allows for more flexibility in how they're written. The main disadvantage seems to me to be that it makes looking for formats less precise, or at least more tedious.)
- In any case, if the type codes are listed in pairs along with creator codes, I'm definitely in favor of some sort of separator (e.g. a '/') between them, because the MediaWiki search (at least for whatever version is being run here) does not seem to be able to search for substrings (a search for a substring of "format", for example, returns no results). I am also interested in seeing how non-ASCII type or creator codes would be represented.
- (Unlike the last time this was discussed, I am now in favor of using (a) template(s) for the codes.) Effect2 (talk) 19:28, 9 May 2019 (UTC)
- It seems to me like absolute positions on whether or not creator codes should be listed, "not at all" and "always, in the infobox", both have dislikable consequences:
