(Model) Chapter vs. Parts (Discussion)

[cloudiirain]

Recently, @GetRektByMe and me have been discussing models for the database. Recchan's suggestion can be found here, whereas mine can be found here.

One of the major points where we differ is whether there should be a class for Parts of a chapter.

What are Parts?

• Parts are part of the logical organization of many chapters. For example, Chapter 1 Part 1, Chapter 1 Part 2, etc. They are essentially subdivisions of a chapter.
• Some but not all series have chapters physically divided into parts in the raws. These parts may or may not be numbered -- often times they will contain some extra empty lines or a bunch of symbols to indicate the parts: (e.g. <center>* * *</center>)
• Not all translators choose to subdivide their translations into parts
  • Some translators arbitrarily publish "parts" on their wordpress blogs where there is no actual break in the text. They do it because they're working on a super long chapter (note: some series have chapters that are as long as the entire volume, 100k characters+), and if they waited until there was an actual breakpoint in the raw..... they'd never get there..... so they publish in reasonably sized arbitrary chunks.
  • Note that some translators will do weird things and publish two chapters in one post... I've seen it before.
• Some parts are ridiculously short (like... 5-7 lines). Just so you know, if you go by the <center>* * *</center> definition for where a part starts/end.

  Why Parts? (@GetRektByMe can probably advocate for this better)

• For EPUB support. When generating EPUBs, subparts of a chapter should be handled differently from chapters.
• Gives translators the flexibility to upload however much they want, rather than entire chapters.
• Readability - parts can subdivide large chapters into smaller sections.

  What is the difference between Recchan's and My suggestion on how to implement Parts?

• Recchan suggested having a separate Class/Model/Table for Parts, with a one-to-many relationship to Chapters. No text would be stored at the chapter level. A chapter with no parts would just have one part. Example:

Chapter 1

• Part 1
• Part 2
• Part 3

Chapter 2

• Part 1
• Part 2

Chapter 3 <-- only one part, so link at this level Chapter 4

• I suggested having any Part-related logic as fields of Chapter. For instance, we could have an is_part field with a boolean that marks this "chapter" as only a part, which would signal it for different behavior on EPUB generation. Order of the parts could be inferred from chapter order. Example:

Chapter 1 Part 1 Chapter 1 Part 2 Chapter 1 Part 3 Chapter 2 Part 1 Chapter 2 Part 2 Chapter 3 Chapter 4

Note that you could also achieve this layout with Recchan's model by rendering all the parts merged together in one view. (Just saying it's not hard to do, and the layout on the UI shouldn't determine how the model design takes place

Why a separate class for Parts?

• Because it's easier for implementing the EPUB?
• Because it logically makes sense
• Ask @GetRektByMe and @scraeling (it's not what I support)

  Why not a separate class for Parts

• Because simplicity
• More challenging to write code with a separate class with Parts, and our life will be a lot easier if we didn't add this extra class, especially given the other issues we're dealing with (revision history and multiple translators submitting translations of the same chapter).
• UX is a little bit more complicated with a class for Parts

I'll elaborate on the third point more.

Generally speaking, in relational databases, you need to create the independent object before the dependent object in one-to-many relationships. For instance, Series must be created before you start creating Chapters for the series.

If we add another relationship at this point, UX is more complicated because a translator must first create the Chapter before creating the Part. This is generally done in either two POST requests (meaning a page refresh between the two), or two AJAX requests (at least to check whether a new chapter exists/fetching a list of chapters on the select form)... or 1 AJAX request (creating a chapter and part at the same time) if you're confident the chapter doesn't exist.

I mean, as a translator uploading something, I don't really care whether the model on our app takes things as parts or as a full chapter. I just want to upload something that I translated. I'm looking to select the series that I'm translating, type the name of my chapter (if it's a part, just specify it in the title), paste and upload!

With parts as an additional class, I need to select the series I'm translating, select the chapter this part belongs to (or none at all), type the name of my part (which in most cases is just a chapter), paste and upload! There's one more user interaction (which doesn't make sense to a translator who doesn't use parts and always uploads full chapters).

[cloudiirain]

In relation to this issue (retranslations of the same chapter), I think it's important to point out that translators do make arbitrary breaks/divisions and call them parts. We also have no way of policing/enforcing translators to use to same convention for defining what constitutes or does not constitute a part.

Therefore a part divisions defined by Translator Joe may not be the same part divisions defined by Translator Bob in a retranslation situation.

[danieltanfh95]

Can I know how does epub generators parse the page for parts? like how do it know that this is a part.

[byronvanstien]

Parts on chapters were both added in 434c0d0 the displaying of this will be handled in the front end, which will check if the highest position is 0, and will omit the Part 1 if it is