Merge dev branch into master

[joyeusenoelle]

Updates go-bindata url.

Adds value attribute to RTL checkbox on "Edit post metadata" page.

Changes RTL on the server side to use integers instead of boolean values. This has the advantage of supporting the auto setting: 0 is LTR, 1 is RTL, 2 is auto. -1 should be used in the case that no setting is used, but that should never happen.

That third change requires substantial review. Please don't merge this PR without making sure they do what we want them to.

---

• I have signed the CLA

[thebaer]

Hey @joyeusenoelle, before you make any more progress on this, what's the rationale behind the RTL changes? What benefit does 0 / 1 / 2 have over false / true / NULL (respectively)?

[joyeusenoelle]

The initial condition that prompted my change was that the database was storing the value as 1 or 0 already. I'm genuinely not sure what caused that behavior, and the intent of this change was, at least in part, to see if it fixed the problem!

However, it occurs to me that moving from true/false/NULL to an integer-based system allows for certain additional features; for example, we might expand to 3 to allow someone to post RTL and vertical (such as Japanese text often is), where t/f/N would struggle with that and require an extra variable on the back end.

I also confess that I have a distaste for NULL being used as a meaningful state, but that's just me.

[thebaer]

Right, that's how the Go database drivers store booleans, since MySQL and SQLite don't have a native boolean type (in MySQL it's stored as a TINYINT and in SQLite it's an INT). The general goal, I'd say, is to leave that particular abstraction up to the db drivers, and then at the application layer use the static types that most closely represent the data.

In the case of this field, it exists for a very specific purpose: to indicate whether a post should display left-to-right (for languages like English) or right-to-left (for languages like Arabic). The optional NULL state informs the application whether or not the user ever explicitly provided the value (this is pretty standard practice for designing schemas). But the important point to note is that the "auto" behavior is delegated to clients, not the server. In general, we want the stored data to be as unopinionated as possible so that we can always adjust the app behavior if necessary without modifying data -- and I think the current design accomplishes that.

As for other text directions, I'd say that'd make most sense as an additional column in the posts table. But mostly, major sweeping changes like this should ideally have a concrete reason / immediate need.

Lastly, we need to be careful with type changes that involve the database. With this change, any time you SELECTed a post that has a NULL is_rtl value, the app would break. To successfully implement this, we'd need to also add a database migration. But again, I personally don't think we should go in this direction.

[joyeusenoelle]

That's fair enough, and part of the reason I asked for a thorough review. My commits are easy enough to revert. I'll revisit this over the weekend.

[thebaer]

Sounds good 👍