Translators as staff
|#1 by yorhel|
2019-10-15 at 06:02
|Alright, so this has been requested and discussed a bit before (t950.560 most recently). I have no objections at all to adding translation credits, but I do have some questions about how to actually organize this.|
How should should translators be added?
The easiest approach is to just add it as another staff role, next to "Scenario", "Artist", etc. But that gets messy real quick, translators are specific to a certain language and, in some cases, only to certain releases. A VN that's been translated into many languages will have just as many - or more - "Translator" staff listings and notes don't seem like a strong enough method to highlight who worked on which translation.
I could imagine adding a language flag to the role, so you get "English translator", "Russian translator" etc as separate staff roles.
As less messy approach might be to add an additional staff section to release entries, but that'll result in duplicated information and may hurt discoverability.
Should editors be added?
I'd say they can have a pretty significant effect on the readability of a VN, hence yes. How? Yet another separate staff role?
|#2 by kiru|
2019-10-15 at 06:54
|I'd completely separate original staff and localization staff. Just like how it's done in credits of localized games. (first the original staff rolls in its entirety, then the staff of the localizing company rolls) In other words: An entire box just for that.|
It's worthwhile separating this, as usually one has very little to do with the other. I don't think it needs to be on a release basis, unless we start doing that in general with staff was well. There's plenty of examples where staff only worked at a specific version of a VN already.
|#3 by eacil|
2019-10-15 at 06:58
|A new section "Localization Staff" below "Development Staff" would make things clearer and you could hide the whole section if you are not interested in that kind of data. We would not have staff with or without flags jumbled together.|
There is also the case of a VN having multiple localizations like Cross†Channel which had three different teams worked on it. The use case is rare so notes should be enough I guess?
|#4 by curious|
2019-10-15 at 07:23
|I think editor should be added too, they're part of the process. What about the quality assurance team?|
This also applies to fan translators?
|#5 by kiru|
2019-10-15 at 07:50
|If it's done, it should probably be the entire credits. And while that's mostly something for commercial releases, I don't see a reason why it wouldn't be a thing for fan-tls as well, provided they have some sort of official credits. The key point here is: It should be official credits and somewhere distributed with the game or patch. Be it in the credits roll at the end of the game, a separate text document or whatever else. Official websites could work as well, but that's probably only good for not yet released things, as game credits or whatever should be more complete.Last modified on 2019-10-15 at 07:52|
|#6 by ginseigou|
2019-10-15 at 07:54
How should should translators be added?
Just add it into release info.
|#7 by ecchihieronymus|
2019-10-15 at 09:19
|I'm all for #2 and #3.|
#4 Editor would be one of the staff members in that section.
Idk what to do about multiple localisations into the same language, though.
Make it possible to check boxes on your profile for the types of staff that you want to see (All, Development/Original, Boolean for individual localisations [Spanish, English, German, French, Chinese...] Or boolean selection for the staff section over all)Last modified on 2019-10-15 at 09:22
|#8 by dk382⭐|
2019-10-15 at 09:29
|If we're adding localization credits, I would recommend including both translators and editors. I'm biased since I'm also an editor, but they do frequently leave a large impact on the work. It can be a bit confusing because every company (and fan group) has their own standards regarding which role fulfils which responsibilities. Some expect editors to be little more than simple proofreaders, while others expect editors to almost fully rewrite translations into natural language. But because it's possible for them to play significant roles, I think they should be added alongside translators. It's not like we often know exactly how important of a role a lot of the other staff members play in our current database.|
As for QA, those are important in ensuring that final releases are of a polished, good quality, but in the grand scheme of things they don't have a significant impact on the final work. I know that we have tried to limit the staff database from having insignificant roles in the past, and if that's the standpoint we're still working from then we should probably exclude QA. But nowadays it seems like we're adding everyone and their mother to the database, so I guess why not? If the goal is to allow users to follow certain localization staff's bodies of work and to avoid others', then having other team members like QA might muddle things too much. I can see it, though, as long as the UI is built to accommodate them. The other roles to look out for would be hacking/programming/scripting, image editing, and translation checking (TLC), the latter of which usually being for fan translations only.
I think a simple enough way of doing this would be to make localization staff a separate section between current staff and the character summary, and the categories being the language they worked on, with their roles (editor, translator, etc?, as well as for which release if multiple translations of single language) being listed where staff notes are for regular staff. If this would add too much 'bulk' to the VN page, then maybe allow users to collapse regular staff and localization staff with configurable default behaviors?
That is the simple approach because you're not manually assigning individual staff to individual releases. Doing it that way might be too burdensome, imo. Translations often come with multiple releases, and if we have a lot of staff being added then it could simply be a pain in the ass adding them to each individual release. Simply mentioning what release(s) they're tied to in the notes should be good enough and less burdensome when editing. For example, with Muv-Luv Alternative, the notes might look something like this:
Ixrec - Translator - Fan translation (r10816)
????? - Editor - Fan translation (r10816)
Enjoievan - Translator - Degica, PQube releases (r43374 + others)
Relying on notes instead of a codified system would leave things up to each individual editor as to how they want to present this information, but I feel like we can get a decent, readable look doing it that way. I'm just worried that having codified system with individual roles attached to individual releases for individual languages, etc, would make editing in this info much harder than it has to be.
I also prefer doing categories/columns by language instead of role because it allows people to more easily gather information at a glance. The alternative is the way the current staff db works with different roles separated into different columns, and we'd further specify language somehow? I get the feeling users will want to look for all the staff that worked on a specific language's translation first and foremost, so we should design the interface with that in mind.Last modified on 2019-10-15 at 10:01
|#9 by yorhel|
2019-10-15 at 11:10
|#8 looks like an excellent proposal.|
I'd slightly change the way that localization staff is displayed, though. I understand wanting to have this as a separate section, but the current staff listings are already quite sparse, a separate section is going to make that even worse. So I'm more inclined to include localization section in the same view, with the titles being "English localization" and the rest pretty much as proposed.
If it's done, it should probably be the entire credits.My opinion on the scope hasn't changed all that much. If anything, this thread is a perfect example of why "just add everything" is a bad idea: The data model and presentation need to be adjusted in order to support new roles well. Adding support for more roles without much forethought is going to get messy real fast, and for what purpose? What is the value in knowing who beta-tested a game? Will it influence your decision in any way? (Those are honest questions, not criticizing)
This thread just made me realize that the data model for seiyuu is also too limited, it should have an additional language field as well to support dubs. But that's not really a thing right now, to my knowledge.
|#10 by eacil|
2019-10-15 at 11:21
|A good way to debloat this section would be to allow the user to whitelist the languages they are interested in because for a VN like Saya no Uta you have 12 different languages and I surely do not care about who worked on the tl which are either not in English or in my native language. I assume this will be the same for everyone.|
This will also reduce the need for JS to hide the bloat on popular VN and allow users using languages stuck at the bottom of the queue to actually see them straight away.
I am saying whitelist but it could be a versatile list you can either use as a whitelist or a blacklist. I don't think it will change a lot programmatically but I might be wrong. I thought about that for tags, actually.
And while we are at it, maybe some people would want to use this list to hide releases? (I am personally not interested.)
|#11 by yorhel|
2019-10-15 at 11:26
|A little personalization is fine here and there, but 99% of people are going to stick with the defaults, so those should simply not suck™. I'd much rather focus my efforts on that than on patching up uglyness with "yeah you can change that".|
|#12 by rampaa|
2019-10-15 at 14:33
|I think translators (and editors) should be added in the same way Publishers/Engines are added. It's a release specific information, it ought to be handled in that level as well. A VN might be available in dozens of different languages and even for a specific language, there might be more than one translation. And I am sure most people would not care who translated a VN into a language they don't even speak. Handling it on the same scope of staff would make things look messier in my opinion. |
Adding *any* information on a release-base is a hassle, I am aware. But that doesn't really convince me about how it ought to be solved. Maybe if we could somehow add the same information to multiple releases at once, that would greatly help in that regard as well.
This also makes total sense for searching purposes. Say, I want to avoid translator X. How do I do that if we handle translator field in the staff section? Someone other than X might have translated the same VN to, say, English. If that is the case, excluding X from my release filters should still return such a VN. But if it's handled in the staff section, it will be excluded no matter what, even if there's an alternative translation in the same language.Last modified on 2019-10-15 at 14:52
|#13 by kiru|
2019-10-15 at 18:30
|@9: I actually don't think quality check is even part of normal credits. At least not name by name. Usually it's stuff like "all staff", which makes sense. Everyone should probably look over the work a bit and see if it works. Beta testers are not part of normal credits either.|
I was more thinking about the director/project leader, translators, editors, programmers and such. Once again, mostly looking at the commercial side of things. I can see how this can be awkward for fan translations. But that would essentially cover the same ideas that we currently have. (translators+editors:writer+assistant writers, director = director, script=script aka programming work, this all exists for the original staff.)
@12: Then you'd also need to change where writers and whatnot are. Because writers can easily only write for one version of the game and have nothing to do with the other ones. (usually the unfortunate souls writing the dreaded additional content for re-releases..) I can definitely see how it can get messy for games with many languages and completely different releases, but how many cases will there be and aren't they already messy? Can't be worse than those games with 10 writers.Last modified on 2019-10-15 at 18:32
|#14 by rampaa|
2019-10-15 at 18:48
|#13: Even if we don't care about the messiness, filtering issue is one of my main concerns. If I don't want to see translations of X, that does not imply that I am not interested in the alternative translations. For arguments sake, let's say I hate the guy who translated r53017, that does not imply I do not want to see r2641 when I filter that guy out. And I believe many people would agree with me on that part. Not making translators field release-specific seems too counterproductive to me.Last modified on 2019-10-15 at 18:48|
|#15 by dk382⭐|
2019-10-15 at 23:33
|I don't think it was ever in the plans to let users filter out releases based on staff involved. That seems to me like it would be of limited usefulness. Just look to see who was responsible for which release in the staff notes (similar to how we do it now) and then not get that release.|
|#16 by rampaa|
2019-10-15 at 23:49
|I disagree. Being able to filter by the information we have is very important. I definitely know that I would use it. Putting translators field into staff section is the more "limiting" option here. And honestly, I don't get why filtering releases based on their publishers is useful enough to warrant a filter but doing the same thing for translators would have "limited usefulness".Last modified on 2019-10-16 at 00:00|
|#17 by uvix|
2019-10-16 at 02:01
This thread just made me realize that the data model for seiyuu is also too limited, it should have an additional language field as well to support dubs. But that's not really a thing right now, to my knowledge.There's a few, mostly from Spike Chunsoft - AI: The Somnium Files and Dangan Ronpa Kibou no Gakuen to Zetsubou no Koukousei and sequels come to mind.
|#18 by lucumo|
2019-10-16 at 14:52
|I generally agree with tying translators, editors etc to specific releases (so basically what #12 said).|
Additionally, more filters are always welcome. So in the case that the staff is displayed in general, for every single release in every language, I would certainly want to filter that out.
|#19 by myopius|
2019-10-16 at 15:48
|I pretty much agree with everything @8/dk382 said... I think it makes sense to essentially build off the existing staff database. The idea that it's necessary to put localization staff in release info contrasts with how we associate characters with individual releases (for an example, the Shuffle Essence heroines). Plus like dk382 said, the nail in the coffin is that localizations often have multiple releases.|
I do question whether it makes sense to freely link to releases within notes. I'd rather alter the localization staff DB (I mean, copy the localization staff DB's table but then modify it) to have an additional parameter for a release (chosen by some guideline) or a list of releases, similar to what's done to associate characters with releases. Without that, it could become too messy: Multiple releases would be (r#####) (r#####) etc. Data entry would need to confirm that the string ends in (r#####). It seems like a DB design that could weaken the connections between data in the DB, making it impossible to use a simple query to determine the localization staff associated with a particular release.
Anyway, translators and editors indeed seem like candidates for major roles. If people want to add other localization credits, theoretically they could utilize an equivalent of the generic "Staff" subsection which is used for minor roles in development staff... Although my personal opinion is that the "Staff" subsection is already really cluttered as it is. At least in the initial tests, it would probably be better to focus on major roles.Last modified on 2019-10-16 at 15:56
|#20 by yorhel|
2019-10-17 at 08:15
|Searchability and being able to exclude translators *is* indeed a pretty valuable feature, but I'm not sure it's worth throwing this to releases. The character<->release relations are a good example, while we do have that, I can't say I'm fond of that solution - with the many different releases it's not easy to get a clear overall picture. While assigning translators to releases is much better in terms of searchability, it does still have a pathological problem when multiple translators work on a release and the translator you're excluding has only done an insignificant part of it. This problem seems impossible to avoid, but is unlikely to be a big issue.|
One way to solve the searchability problem without going for releases is to add different staff sections for different editions, like:
English localization #1 (r10816, etc)In which case the search query would become "exclude all visual novels which have at least one English translation where X is not on the staff".
Ixrec - Translator
????? - Editor
English localization #2 (Degica, PQube releases, r43374 + others)
Enjoievan - Translator
Generalizing even further, the problem has always been that release entries are too specific and visual novel entries too generic, we need something in between in order to handle cases like these. Hence "Editions": editions could be defined separately and releases could be tagged to belong to one or more editions; Staff and characters can then be more easily and clearly tagged with the respective edition. That's quite an extension to our current model, though, and I've yet to convince myself it's a good idea to go in that direction...
|#21 by rampaa|
2019-10-17 at 16:17
exclude all visual novels which have at least one English translation where X is not on the staffI thought it would be more along the lines of "Exclude all visual novels that have X as a translator for all English translations".
As I see it, not having a proper translator<->release relationship has still have a few other problems. For example, we won't just add translators for complete translations, right? Translations of trials and partial translations will be credited as well. So X might be actually the only one who translated a VN fully but since we won't know this through staff relationship we won't be able to exclude this VN from the results. Same goes for age ratings. If I am only interested in 18+ editions and if X is the only one that has translated the 18+ edition of a VN, that VN should be excluded because even if there are different translations for the VN, those translations are not for the 18+ editions.
In order to have a proper staff<->release relationship without making it too hard to link them, an additional field might be added to staff section. This way, instead of noting the relation through a free-form textbox, the relevant releases could be selected easily. So it would be something like "Staff-Credit-Releases-Note". But I am not sure how the end result would be shown in the UI.
Generalizing even further, the problem has always been that release entries are too specific and visual novel entries too genericCouldn't agree more. Tags, being one of the most (if not the most) important part of VNDB, suffer from this too much. I'm not too sure how this can be solved in general but hopefully we will have a better model for them one day.
Hence "Editions"I ship it.Last modified on 2019-10-17 at 16:28
|#22 by myopius|
2019-10-17 at 21:31
|The more details of VNs VNDB attempts to catalogue, the more likely they'll be associated with releases rather than the VN overall, and the more people will chafe against the fact VNDB chose a model that's different from EGs. I'm not sure it's possible to ever completely satisfy people who want to differentiate between niches, though.|
I often think back to how staff notes have been subjected to many mass re-edits for standardization and uniformity. So when it comes to the issue of whether a localization staff's associated releases are specified via hyperlinks in localization staff notes (like "(r#####, etc)") or via a drop-down list of releases (like character<->release relations)... I leaned toward the latter, simply because I wonder why you'd want to have one of the most critical and essential pieces of data when it comes to localization staff credits--the associated releases--be a part of the mutable string-based localization staff notes, where it'd be subject to such stylization and formatting concerns. That is, I don't know why a "character<->release relation"-esque drop-down list wouldn't be appropriate to have if that relation exists for 100% of localization credits. Maybe I just lack a sufficient understanding of the database's logistics. Either way, I'm sure that a testing period will uncover any issues, so I'm not worried.
You must be logged in to reply to this thread.