Spell check, add translation files and publish article on local-first software

10 files changed, 2510 insertions, 31 deletions

diff --git a/_articles/2020-10-26-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md b/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md
index 409dfaf..1a41c0c 100644
--- a/_articles/2020-10-26-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md
+++ b/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md
@@ -12,8 +12,6 @@ ref: local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review
 
 eu_categories: presentation,article review
 
-published: false
-
 ---
 
 *This article is derived from a [presentation][presentation] given at a Papers
@@ -40,10 +38,10 @@ that "local-first" is just "offline-first", but with 7 well-defined ideals
 instead of community best practices.
 
 It is a step forward, and given the number of times I've seen the paper shared
-around I think there's a chance people will prefer saying "local-first" in lieu
-of "offline-first" from now on.
+around I think there's a chance people will prefer saying "local-first" in
+*lieu* of "offline-first" from now on.
 
-[presentation]: {% link _slides/2020-10-26-on-local-first-beyond-the-crdt-silver-bullet.slides %}
+[presentation]: {% link _slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides %}
 [article-pdf]: https://martin.kleppmann.com/papers/local-first.pdf
 
 ### Software licenses
@@ -55,7 +53,8 @@ the authors say:
 > the software must necessarily be open source. (...) as long as it does not
 > artificially restrict what users can do with their files.
 
-They give examples of artificial restrictions, like this one:
+They give examples of artificial restrictions, like this artificial restriction
+I've come up with:
 
 ```bash
 #!/bin/sh
@@ -103,12 +102,12 @@ $ useful-program
 ERROR: Panic! Stack overflow!
 ```
 
-Just as easily as I can come up with ways to intentionally restrict users, just
-as easily I can do the same for unintentionally restricting users. A program can
-stop working for a variety of reasons.
+Just as easily as I can come up with ways to intentionally restrict users, I can
+do the same for unintentionally restrictions. A program can stop working for a
+variety of reasons.
 
-If it stops working due do data growth, what are the options? Reverting to an
-earlier backup, and making it read-only? That isn't really a "Long Now", but
+If it stops working due do, say, data growth, what are the options? Reverting to
+an earlier backup, and making it read-only? That isn't really a "Long Now", but
 rather a "Long Now as long as the software keeps working as expected".
 
 The point is: if the software isn't free/libre, "The Long Now" isn't achievable
@@ -125,16 +124,16 @@ it, just makes it possible.
 
 A colleague has challenged my view, arguing that the software doesn't really
 need to be free, as long as there is an specification of the file format. This
-way is the software stops working, the format can still be processed by other
+way if the software stops working, the format can still be processed by other
 programs. But this doesn't apply in practice: if you have a document that you
 write to, and software stops working, you still want to write to the document.
 An external tool that navigates the content and shows it to you won't allow you
-to keep writing, and when it does that tool is now starting to reimplement the
+to keep writing, and when it does that tool is now starting to re-implement the
 software.
 
 An open specification could serve as a blueprint to other implementations,
 making the data format more friendly to reverse-engineering. But the
-reimplementation still has to exist, at which point the original software failed
+re-implementation still has to exist, at which point the original software failed
 to achieve "The Long Now".
 
 It is less bad, but still not quite there yet.
@@ -172,10 +171,10 @@ problem with it? If so, what is it, and how to avoid it?
 
 If sending patches by emails is perfectly possible but out of fashion, why even
 talk about Git/GitHub? Isn't this a problem that people are putting themselves
-in? How can CDRTs possibly prevent people from doing that?
+in? How can CRDTs possibly prevent people from doing that?
 
 My impression is that the authors envision a better future, where development is
-fully decentralized unlike today, and somehow CDRTs will make that happen. If
+fully decentralized unlike today, and somehow CRDTs will make that happen. If
 more people think this way, "CRDT" is next in line to the buzzword list that
 solves everything, like "containers", "blockchain" or "machine learning".
 
@@ -205,7 +204,7 @@ In fact, many people choose [PouchDB][pouchdb] *because* of that, since it is a
 good tool for offline-first web applications. The problem isn't really the
 technology, but how much people want their application to be local-first.
 
-Constrast it with Android [Instant Apps][instant-apps], where applications are
+Contrast it with Android [Instant Apps][instant-apps], where applications are
 sent to the phone in small parts. Since this requires an internet connection to
 move from a part of the app bundle to another, a subset of the app isn't
 local-first, despite being an app.
@@ -219,7 +218,7 @@ applications are possible.
 
 ### Costs are underrated
 
-I think the costs of "old-fashined apps" over "cloud apps" are underrated,
+I think the costs of "old-fashioned apps" over "cloud apps" are underrated,
 mainly regarding storage, and that this costs can vary a lot by application.
 
 Say a person writes online articles for their personal website, and puts
@@ -229,7 +228,7 @@ of the relevant ideals of local-first are achieved.
 Now another person creates videos instead of articles. They could try keeping
 everything local, but after some time the storage usage fills the entire disk.
 This person's local-first setup would be much more complex, and would cost much
-more on maintenence, backup and storage.
+more on maintenance, backup and storage.
 
 Even though both have similar needs, a local-first video repository is much more
 demanding. So the local-first thinking here isn't "just keep everything local",
@@ -239,7 +238,7 @@ The convenience of "cloud apps" becomes so attractive that many don't even have
 a local copy of their videos, and rely exclusively on service providers to
 maintain, backup and store their content.
 
-The dial measuring "cloud apps" and "old-fashined apps" needs to be specific to
+The dial measuring "cloud apps" and "old-fashioned apps" needs to be specific to
 use-cases.
 
 ### Real-time collaboration is optional
@@ -259,8 +258,8 @@ to find people saying that their application works
 "even on a plane, subway or elevator". That is a reflection of when said
 developers have to deal with networks being unavailable.
 
-But this leaves out a big chunck of the world where internet connection is
-intermittent, or only work every other day or only once a week, or stops
+But this leaves out a big chunk of the world where internet connection is
+intermittent, or only works every other day or only once a week, or stops
 working when it rains, *etc*. For this audience, living without network
 connectivity isn't such a discrete moment in time, but part of every day life. I
 like the fact that the authors acknowledge that.
@@ -286,8 +285,9 @@ system.
 Adding a large layer of data structures and algorithms will make it more complex
 to write software for, naturally. And if trying to make this layer transparent
 to the programmer, so they can pretend that layer doesn't exist is a bad idea,
-as RPC frameworks have tried, and failed. See
-"[A Note on Distributed Computing][note-dist-comp]" for a critique on RPC
+as RPC frameworks have tried, and failed.
+
+See "[A Note on Distributed Computing][note-dist-comp]" for a critique on RPC
 frameworks trying to make the network invisible, which I think also applies in
 equivalence for making the CRDTs layer invisible.
 
@@ -301,3 +301,6 @@ with it.
 
 But I think the authors' view of adding CRDTs and things becoming local-first is
 a bit too magical.
+
+This particular area is one that I have large interest on, and I wish to see
+more being done on the "local-first" space.
diff --git a/_slides/2020-10-26-on-local-first-beyond-the-crdt-silver-bullet.slides b/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides
index 02f6cc7..425648f 100644
--- a/_slides/2020-10-26-on-local-first-beyond-the-crdt-silver-bullet.slides
+++ b/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides
@@ -2,7 +2,7 @@
 
 title: 'On "local-first": beyond the CRDT silver bullet'
 
-date: 2020-10-26
+date: 2020-11-14
 
 layout: slides
 
@@ -10,8 +10,6 @@ lang: en
 
 ref: on-local-first-beyond-the-crdt-silver-bullet
 
-published: false
-
 ---
 
 # On local-first
@@ -26,7 +24,7 @@ Exposition
 
 ---
 
-## "cloud apps" vs "old-fashined apps"
+## "cloud apps" vs "old-fashioned apps"
 
 ---
 
@@ -201,7 +199,7 @@ Why not exploit that more?
 
 > The architecture of web apps remains fundamentally server-centric
 
-Disagree. Constrast [PouchDB][pouchdb] with Android [Instant Apps][instant-apps]
+Disagree. Contrast [PouchDB][pouchdb] with Android [Instant Apps][instant-apps]
 
 [pouchdb]: https://pouchdb.com/
 [instant-apps]: https://developer.android.com/topic/google-play-instant
@@ -216,7 +214,7 @@ Talk on dynamic content
 
 - storage
 - backups
-- maintanence
+- maintenance
 
 Example: blog vs vlog
 
@@ -262,7 +260,7 @@ The tricky part is the end of the sentence: "**in spite of the Cloud**".
 References:
 
 1. these slides: [{{ site.tld }}/slides.html]({% link slides.md %})
-2. [prose version of this presentation]({% link _articles/2020-10-26-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %})
+2. [prose version of this presentation]({% link _articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %})
 3. "[Local-First Software: You Own Your Data, in spite of the Cloud](https://martin.kleppmann.com/papers/local-first.pdf)",
  by M. Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan
 4. [The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-software/)
diff --git a/locale/eo/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po b/locale/eo/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po
new file mode 100644
index 0000000..ade1529
--- /dev/null
+++ b/locale/eo/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po
@@ -0,0 +1,497 @@
+#
+msgid ""
+msgstr ""
+
+msgid ""
+"title: \"Local-First Software: You Own Your Data, in spite of the Cloud - "
+"article review\""
+msgstr ""
+
+msgid "date: 2020-11-14"
+msgstr ""
+
+msgid "layout: post"
+msgstr ""
+
+msgid "lang: en"
+msgstr ""
+
+msgid ""
+"ref: local-first-software-you-own-your-data-in-spite-of-the-cloud-article-"
+"review"
+msgstr ""
+
+msgid "eu_categories: presentation,article review"
+msgstr ""
+
+msgid ""
+"*This article is derived from a [presentation][presentation] given at a "
+"Papers We Love meetup on the same subject.*"
+msgstr ""
+
+msgid ""
+"This is a review of the article \"[Local-First Software: You Own Your Data, "
+"in spite of the Cloud][article-pdf]\", by M. Kleppmann, A. Wiggins, P. Van "
+"Hardenberg and M. F. McGranaghan."
+msgstr ""
+
+msgid "Offline-first, local-first"
+msgstr ""
+
+msgid ""
+"The \"local-first\" term they use isn't new, and I have used it myself in "
+"the past to refer to this types of application, where the data lives "
+"primarily on the client, and there are conflict resolution algorithms that "
+"reconcile data created on different instances."
+msgstr ""
+
+msgid ""
+"Sometimes I see confusion with this idea and \"client-side\", \"offline-"
+"friendly\", \"syncable\", etc. I have myself used this terms, also."
+msgstr ""
+
+msgid ""
+"There exists, however, already the \"offline-first\" term, which conveys "
+"almost all of that meaning. In my view, \"local-first\" doesn't extend "
+"\"offline-first\" in any aspect, rather it gives a well-defined meaning to "
+"it instead. I could say that \"local-first\" is just \"offline-first\", but "
+"with 7 well-defined ideals instead of community best practices."
+msgstr ""
+
+msgid ""
+"[presentation]: {% link _slides/2020-11-14-on-local-first-beyond-the-crdt-"
+"silver-bullet.slides %} [article-pdf]: "
+"https://martin.kleppmann.com/papers/local-first.pdf"
+msgstr ""
+
+msgid "Software licenses"
+msgstr ""
+
+msgid ""
+"On a footnote of the 7th ideal (\"You Retain Ultimate Ownership and "
+"Control\"), the authors say:"
+msgstr ""
+
+msgid ""
+"In our opinion, maintaining control and ownership of data does not mean that"
+" the software must necessarily be open source. (...) as long as it does not "
+"artificially restrict what users can do with their files."
+msgstr ""
+
+msgid ""
+"#!/bin/sh\n"
+"\n"
+"TODAY=$(date +%s)\n"
+"LICENSE_EXPIRATION=$(date -d 2020-11-15 +%s)\n"
+"\n"
+"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n"
+"  echo 'License expired!'\n"
+"  exit 1\n"
+"fi\n"
+"\n"
+"echo $((2 + 2))\n"
+msgstr ""
+
+msgid "Now when using this very useful program:"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ ./useful-adder.sh\n"
+"4\n"
+"# tomorrow\n"
+"$ ./useful-adder.sh\n"
+"License expired!\n"
+msgstr ""
+
+msgid ""
+"This is obviously an intentional restriction, and it goes against the 5th "
+"ideal (\"The Long Now\"). This software would only be useful as long as the "
+"embedded license expiration allowed. Sure you could change the clock on the "
+"computer, but there are many other ways that this type of intentional "
+"restriction is in conflict with that ideal."
+msgstr ""
+
+msgid ""
+"However, what about unintentional restrictions? What if a software had an "
+"equal or similar restriction, and stopped working after days pass? Or what "
+"if the programmer added a constant to make the development simpler, and this"
+" led to unintentionally restricting the user?"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ useful-program\n"
+"# ...useful output...\n"
+"\n"
+"# tomorrow, with more data\n"
+"$ useful-program\n"
+"ERROR: Panic! Stack overflow!\n"
+msgstr ""
+
+msgid ""
+"The point is: if the software isn't free/libre, \"The Long Now\" isn't "
+"achievable without a lot of wishful thinking. Maybe the authors were trying "
+"to be more friendly towards business who don't like FOSS, but in doing so "
+"they've proposed a contradiction by reconciling \"The Long Now\" with "
+"proprietary software."
+msgstr ""
+
+msgid ""
+"It isn't the same as saying that any free/libre software achieves that "
+"ideal, either. The license can still be free, but the source code can become"
+" unavailable due to cloud rot. Or maybe the build is undocumented, or the "
+"build tools had specific configuration that one has to guess. A piece of "
+"free/libre software can still fail to achieve \"The Long Now\". Being free "
+"doesn't guarantee it, just makes it possible."
+msgstr ""
+
+msgid ""
+"An open specification could serve as a blueprint to other implementations, "
+"making the data format more friendly to reverse-engineering. But the re-"
+"implementation still has to exist, at which point the original software "
+"failed to achieve \"The Long Now\"."
+msgstr ""
+
+msgid "It is less bad, but still not quite there yet."
+msgstr ""
+
+msgid "Denial of existing solutions"
+msgstr ""
+
+msgid ""
+"When describing \"Existing Data Storage and Sharing Models\", on a "
+"footnote[^devil] the authors say:"
+msgstr ""
+
+msgid ""
+"[^devil]: This is the second aspect that I'm picking on the article from a "
+"footnote. I guess the devil really is on the details."
+msgstr ""
+
+msgid ""
+"In principle it is possible to collaborate without a repository service, "
+"e.g. by sending patch files by email, but the majority of Git users rely on "
+"GitHub."
+msgstr ""
+
+msgid ""
+"The authors go to a great length to talk about usability of cloud apps, and "
+"even point to research they've done on it, but they've missed learning more "
+"from local-first solutions that already exist."
+msgstr ""
+
+msgid ""
+"Say the automerge CRDT proves to be even more useful than what everybody "
+"imagined. Say someone builds a local-first repository service using it. How "
+"will it change anything of the Git/GitHub model? What is different about it "
+"that prevents people in the future writing a paper saying:"
+msgstr ""
+
+msgid ""
+"In principle it is possible to collaborate without a repository service, "
+"e.g. by using automerge and platform X, but the majority of Git users rely "
+"on GitHub."
+msgstr ""
+
+msgid "How is this any better?"
+msgstr ""
+
+msgid ""
+"If it is already [possible](https://drewdevault.com/2018/07/23/Git-is-"
+"already-distributed.html) to have a local-first development workflow, why "
+"don't people use it? Is it just fashion, or there's a fundamental problem "
+"with it? If so, what is it, and how to avoid it?"
+msgstr ""
+
+msgid ""
+"If sending patches by emails is perfectly possible but out of fashion, why "
+"even talk about Git/GitHub? Isn't this a problem that people are putting "
+"themselves in? How can CRDTs possibly prevent people from doing that?"
+msgstr ""
+
+msgid ""
+"My impression is that the authors envision a better future, where "
+"development is fully decentralized unlike today, and somehow CRDTs will make"
+" that happen. If more people think this way, \"CRDT\" is next in line to the"
+" buzzword list that solves everything, like \"containers\", \"blockchain\" "
+"or \"machine learning\"."
+msgstr ""
+
+msgid ""
+"Rather than picturing an imaginary service that could be described like "
+"\"GitHub+CRDTs\" and people would adopt it, I'd rather better understand why"
+" people don't do it already, since Git is built to work like that."
+msgstr ""
+
+msgid "Ditching of web applications"
+msgstr ""
+
+msgid ""
+"The authors put web application in a worse position for building local-first"
+" application, claiming that:"
+msgstr ""
+
+msgid ""
+"(...) the architecture of web apps remains fundamentally server-centric. "
+"Offline support is an afterthought in most web apps, and the result is "
+"accordingly fragile."
+msgstr ""
+
+msgid "Well, I disagree."
+msgstr ""
+
+msgid ""
+"The problem isn't inherit to the web platform, but instead how people use "
+"it."
+msgstr ""
+
+msgid ""
+"I have myself built offline-first applications, leveraging IndexedDB, App "
+"Cache, *etc*. I wanted to build an offline-first application on the web, and"
+" so I did."
+msgstr ""
+
+msgid ""
+"In fact, many people choose [PouchDB](https://pouchdb.com/) *because* of "
+"that, since it is a good tool for offline-first web applications. The "
+"problem isn't really the technology, but how much people want their "
+"application to be local-first."
+msgstr ""
+
+msgid ""
+"Contrast it with Android [Instant "
+"Apps](https://developer.android.com/topic/google-play-instant), where "
+"applications are sent to the phone in small parts. Since this requires an "
+"internet connection to move from a part of the app bundle to another, a "
+"subset of the app isn't local-first, despite being an app."
+msgstr ""
+
+msgid ""
+"The point isn't the technology, but how people are using it. Local-first web"
+" applications are perfectly possible, just like non-local-first native "
+"applications are possible."
+msgstr ""
+
+msgid "Costs are underrated"
+msgstr ""
+
+msgid ""
+"I think the costs of \"old-fashioned apps\" over \"cloud apps\" are "
+"underrated, mainly regarding storage, and that this costs can vary a lot by "
+"application."
+msgstr ""
+
+msgid ""
+"Say a person writes online articles for their personal website, and puts "
+"everything into Git. Since there isn't supposed to be any collaboration, all"
+" of the relevant ideals of local-first are achieved."
+msgstr ""
+
+msgid ""
+"Now another person creates videos instead of articles. They could try "
+"keeping everything local, but after some time the storage usage fills the "
+"entire disk. This person's local-first setup would be much more complex, and"
+" would cost much more on maintenance, backup and storage."
+msgstr ""
+
+msgid ""
+"Even though both have similar needs, a local-first video repository is much "
+"more demanding. So the local-first thinking here isn't \"just keep "
+"everything local\", but \"how much time and money am I willing to spend to "
+"keep everything local\"."
+msgstr ""
+
+msgid ""
+"The convenience of \"cloud apps\" becomes so attractive that many don't even"
+" have a local copy of their videos, and rely exclusively on service "
+"providers to maintain, backup and store their content."
+msgstr ""
+
+msgid ""
+"The dial measuring \"cloud apps\" and \"old-fashioned apps\" needs to be "
+"specific to use-cases."
+msgstr ""
+
+msgid "Real-time collaboration is optional"
+msgstr ""
+
+msgid ""
+"If I were the one making the list of ideals, I wouldn't focus so much on "
+"real-time collaboration."
+msgstr ""
+
+msgid ""
+"Even though seamless collaboration is desired, it being real-time depends on"
+" the network being available for that. But ideal 3 states that \"The Network"
+" is Optional\", so real-time collaboration is also optional."
+msgstr ""
+
+msgid ""
+"The fundamentals of a local-first system should enable real-time "
+"collaboration when network is available, but shouldn't focus on it."
+msgstr ""
+
+msgid ""
+"On many places when discussing applications being offline, it is common for "
+"me to find people saying that their application works \"even on a plane, "
+"subway or elevator\". That is a reflection of when said developers have to "
+"deal with networks being unavailable."
+msgstr ""
+
+msgid ""
+"When discussing \"working offline\", I'd rather keep this type of person in "
+"mind, then the subset of people who are offline when on the elevator will "
+"naturally be included."
+msgstr ""
+
+msgid "On CRDTs and developer experience"
+msgstr ""
+
+msgid ""
+"When discussing developer experience, the authors bring up some questions to"
+" be answered further, like:"
+msgstr ""
+
+msgid ""
+"For an app developer, how does the use of a CRDT-based data layer compare to"
+" existing storage layers like a SQL database, a filesystem, or CoreData? Is "
+"a distributed system harder to write software for?"
+msgstr ""
+
+msgid "That is an easy one: yes."
+msgstr ""
+
+msgid ""
+"A distributed system *is* harder to write software for, being a distributed "
+"system."
+msgstr ""
+
+msgid "Conclusion"
+msgstr ""
+
+msgid ""
+"I liked a lot the article, as it took the \"offline-first\" philosophy and "
+"ran with it."
+msgstr ""
+
+msgid ""
+"But I think the authors' view of adding CRDTs and things becoming local-"
+"first is a bit too magical."
+msgstr ""
+
+msgid ""
+"It is a step forward, and given the number of times I've seen the paper "
+"shared around I think there's a chance people will prefer saying \"local-"
+"first\" in *lieu* of \"offline-first\" from now on."
+msgstr ""
+
+msgid ""
+"They give examples of artificial restrictions, like this artificial "
+"restriction I've come up with:"
+msgstr ""
+
+msgid ""
+"Just as easily as I can come up with ways to intentionally restrict users, I"
+" can do the same for unintentionally restrictions. A program can stop "
+"working for a variety of reasons."
+msgstr ""
+
+msgid ""
+"If it stops working due do, say, data growth, what are the options? "
+"Reverting to an earlier backup, and making it read-only? That isn't really a"
+" \"Long Now\", but rather a \"Long Now as long as the software keeps working"
+" as expected\"."
+msgstr ""
+
+msgid ""
+"A colleague has challenged my view, arguing that the software doesn't really"
+" need to be free, as long as there is an specification of the file format. "
+"This way if the software stops working, the format can still be processed by"
+" other programs. But this doesn't apply in practice: if you have a document "
+"that you write to, and software stops working, you still want to write to "
+"the document. An external tool that navigates the content and shows it to "
+"you won't allow you to keep writing, and when it does that tool is now "
+"starting to re-implement the software."
+msgstr ""
+
+msgid ""
+"But this leaves out a big chunk of the world where internet connection is "
+"intermittent, or only works every other day or only once a week, or stops "
+"working when it rains, *etc*. For this audience, living without network "
+"connectivity isn't such a discrete moment in time, but part of every day "
+"life. I like the fact that the authors acknowledge that."
+msgstr ""
+
+msgid ""
+"Adding a large layer of data structures and algorithms will make it more "
+"complex to write software for, naturally. And if trying to make this layer "
+"transparent to the programmer, so they can pretend that layer doesn't exist "
+"is a bad idea, as RPC frameworks have tried, and failed."
+msgstr ""
+
+msgid ""
+"See \"[A Note on Distributed "
+"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\""
+" for a critique on RPC frameworks trying to make the network invisible, "
+"which I think also applies in equivalence for making the CRDTs layer "
+"invisible."
+msgstr ""
+
+msgid ""
+"This particular area is one that I have large interest on, and I wish to see"
+" more being done on the \"local-first\" space."
+msgstr ""
+
+#~ msgid "They give examples of artificial restrictions, like this one:"
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Just as easily as I can come up with ways to intentionally restrict users, "
+#~ "just as easily I can do the same for unintentionally restricting users. A "
+#~ "program can stop working for a variety of reasons."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "If it stops working due do data growth, what are the options? Reverting to "
+#~ "an earlier backup, and making it read-only? That isn't really a \"Long "
+#~ "Now\", but rather a \"Long Now as long as the software keeps working as "
+#~ "expected\"."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "A colleague has challenged my view, arguing that the software doesn't really"
+#~ " need to be free, as long as there is an specification of the file format. "
+#~ "This way is the software stops working, the format can still be processed by"
+#~ " other programs. But this doesn't apply in practice: if you have a document "
+#~ "that you write to, and software stops working, you still want to write to "
+#~ "the document. An external tool that navigates the content and shows it to "
+#~ "you won't allow you to keep writing, and when it does that tool is now "
+#~ "starting to re-implement the software."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "But this leaves out a big chunk of the world where internet connection is "
+#~ "intermittent, or only work every other day or only once a week, or stops "
+#~ "working when it rains, *etc*. For this audience, living without network "
+#~ "connectivity isn't such a discrete moment in time, but part of every day "
+#~ "life. I like the fact that the authors acknowledge that."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Adding a large layer of data structures and algorithms will make it more "
+#~ "complex to write software for, naturally. And if trying to make this layer "
+#~ "transparent to the programmer, so they can pretend that layer doesn't exist "
+#~ "is a bad idea, as RPC frameworks have tried, and failed. See \"[A Note on "
+#~ "Distributed "
+#~ "Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\""
+#~ " for a critique on RPC frameworks trying to make the network invisible, "
+#~ "which I think also applies in equivalence for making the CRDTs layer "
+#~ "invisible."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "It is a step forward, and given the number of times I've seen the paper "
+#~ "shared around I think there's a chance people will prefer saying \"local-"
+#~ "first\" in lieu of \"offline-first\" from now on."
+#~ msgstr ""
diff --git a/locale/eo/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po b/locale/eo/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po
new file mode 100644
index 0000000..7674704
--- /dev/null
+++ b/locale/eo/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po
@@ -0,0 +1,322 @@
+#
+msgid ""
+msgstr ""
+
+msgid "title: 'On \"local-first\": beyond the CRDT silver bullet'"
+msgstr ""
+
+msgid "date: 2020-11-14"
+msgstr ""
+
+msgid "layout: slides"
+msgstr ""
+
+msgid "lang: en"
+msgstr ""
+
+msgid "ref: on-local-first-beyond-the-crdt-silver-bullet"
+msgstr ""
+
+msgid "On local-first"
+msgstr ""
+
+msgid "Beyond the CRDT silver bullet"
+msgstr ""
+
+msgid "Part 1"
+msgstr ""
+
+msgid "Exposition"
+msgstr ""
+
+msgid "\"cloud apps\" vs \"old-fashioned apps\""
+msgstr ""
+
+msgid "Target"
+msgstr ""
+
+msgid "documents"
+msgstr ""
+
+msgid "files"
+msgstr ""
+
+msgid "personal data repositories"
+msgstr ""
+
+msgid ""
+"Not: banking services, e-commerce, social networking, ride-sharing, *etc*."
+msgstr ""
+
+msgid "7 Ideals for local-first software"
+msgstr ""
+
+msgid "1 - No Spinners: Your Work at Your Fingertips"
+msgstr ""
+
+msgid "2 - Your Work Is Not Trapped on One Device"
+msgstr ""
+
+msgid "3 - The Network Is Optional"
+msgstr ""
+
+msgid "4 - Seamless Collaboration with Your Colleagues"
+msgstr ""
+
+msgid "5 - The Long Now"
+msgstr ""
+
+msgid "6 - Security and Privacy by Default"
+msgstr ""
+
+msgid "7 - You Retain Ultimate Ownership and Control"
+msgstr ""
+
+msgid "Towards a Better Future"
+msgstr ""
+
+msgid ""
+"CRDTs (Conflict-free Replicated Data Types) as a Foundational Technology"
+msgstr ""
+
+msgid "Use case"
+msgstr ""
+
+msgid ""
+"# in node A and node B\n"
+"s = \"Hello, World\"\n"
+"\n"
+"# in node A\n"
+"s = \"Hello, Alice\"\n"
+"\n"
+"# in node B\n"
+"s = \"Hello, Bob\"\n"
+msgstr ""
+
+msgid "How to reconcile those?"
+msgstr ""
+
+msgid "`Hello, ABloibce`"
+msgstr ""
+
+msgid "`Hello, AliceBob`"
+msgstr ""
+
+msgid "`Hello, BobAlice`"
+msgstr ""
+
+msgid "`Hello, Alice`"
+msgstr ""
+
+msgid "`Hello, Bob`"
+msgstr ""
+
+msgid "Existing CRDTs differ:"
+msgstr ""
+
+msgid "performance"
+msgstr ""
+
+msgid "storage"
+msgstr ""
+
+msgid "compression"
+msgstr ""
+
+msgid "metadata overhead"
+msgstr ""
+
+msgid "Hint towards the \"automerge\" CRDT"
+msgstr ""
+
+msgid "*show comparison table, page 9*"
+msgstr ""
+
+msgid "Part 2"
+msgstr ""
+
+msgid "Critique"
+msgstr ""
+
+msgid "Software license"
+msgstr ""
+
+msgid ""
+"In our opinion, maintaining control and ownership of data does not mean that"
+" the software must necessarily be open source."
+msgstr ""
+
+msgid "Example 1 - intentional restriction"
+msgstr ""
+
+msgid ""
+"#!/bin/sh\n"
+"\n"
+"TODAY=$(date +%s)\n"
+"LICENSE_EXPIRATION=$(date -d 2020-10-27 +%s)\n"
+"\n"
+"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n"
+"  echo 'License expired!'\n"
+"  exit 1\n"
+"fi\n"
+"\n"
+"echo $((2 + 2))\n"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ ./useful-adder.sh\n"
+"4\n"
+"# tomorrow\n"
+"$ ./useful-adder.sh\n"
+"License expired!\n"
+msgstr ""
+
+msgid "Example 2 - unintentional restriction"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ useful-program\n"
+"# ...useful output...\n"
+"\n"
+"# tomorrow, with more data\n"
+"$ useful-program\n"
+"ERROR: Panic! Stack overflow!\n"
+msgstr ""
+
+msgid "local-first **requires** free/libre software"
+msgstr ""
+
+msgid "Otherwise \"The Long Now\" (ideal nº5) is lost"
+msgstr ""
+
+msgid "Denial of existing solutions"
+msgstr ""
+
+msgid ""
+"In principle it is possible to collaborate without a repository service, "
+"e.g. by sending patch files by email, but the majority of Git users rely on "
+"GitHub."
+msgstr ""
+
+msgid "Solution: either GitHub+CRDTs or `git` **`send-email`**"
+msgstr ""
+
+msgid "Plain text formats"
+msgstr ""
+
+msgid "Git is highly optimized for code and similar line-based text file"
+msgstr ""
+
+msgid "It even pulls software to the plain text direction, e.g.:"
+msgstr ""
+
+msgid "delivery-templates"
+msgstr ""
+
+msgid "`common-core.protocols.config`"
+msgstr ""
+
+msgid "Why not exploit that more?"
+msgstr ""
+
+msgid "Ditching of web applications"
+msgstr ""
+
+msgid "The architecture of web apps remains fundamentally server-centric"
+msgstr ""
+
+msgid ""
+"Disagree. Contrast [PouchDB](https://pouchdb.com/) with Android [Instant "
+"Apps](https://developer.android.com/topic/google-play-instant)"
+msgstr ""
+
+msgid "???"
+msgstr ""
+
+msgid "Talk on dynamic content"
+msgstr ""
+
+msgid "Costs are underrated"
+msgstr ""
+
+msgid "backups"
+msgstr ""
+
+msgid "maintenance"
+msgstr ""
+
+msgid "Example: blog vs vlog"
+msgstr ""
+
+msgid "Real-time collaboration a bit overrated"
+msgstr ""
+
+msgid ""
+"It is only possible on the presence of reliable, medium-quality network "
+"connection"
+msgstr ""
+
+msgid "X also works when inside an elevator, subway or plane!"
+msgstr ""
+
+msgid "On CRDTs and developer experience"
+msgstr ""
+
+msgid ""
+"For an app developer, how does the use of a CRDT-based data layer compare to"
+" existing storage layers like a SQL database, a filesystem, or CoreData? Is "
+"a distributed system harder to write software for?"
+msgstr ""
+
+msgid "Yes."
+msgstr ""
+
+msgid ""
+"See \"[A Note on Distributed "
+"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\""
+msgstr ""
+
+msgid "Conclusion"
+msgstr ""
+
+msgid "Why this is a \"paper I love\": it took offline-first and ran with it."
+msgstr ""
+
+msgid "But a pinch of CRDT won't make the world local-first."
+msgstr ""
+
+msgid "The tricky part is the end of the sentence: \"**in spite of the Cloud**\"."
+msgstr ""
+
+msgid "Thank you!"
+msgstr ""
+
+msgid "References:"
+msgstr ""
+
+msgid "these slides: [{{ site.tld }}/slides.html]({% link slides.md %})"
+msgstr ""
+
+msgid ""
+"[prose version of this presentation]({% link _articles/2020-11-14-local-"
+"first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %})"
+msgstr ""
+
+msgid ""
+"\"[Local-First Software: You Own Your Data, in spite of the "
+"Cloud](https://martin.kleppmann.com/papers/local-first.pdf)\", by M. "
+"Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan"
+msgstr ""
+
+msgid ""
+"[The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-"
+"software/) article"
+msgstr ""
+
+msgid ""
+"\"[A Note on Distributed "
+"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\","
+" by J. Waldo, G. Wyant, A. Wollrath and S Kendall"
+msgstr ""
diff --git a/locale/fr/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po b/locale/fr/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po
new file mode 100644
index 0000000..ade1529
--- /dev/null
+++ b/locale/fr/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po
@@ -0,0 +1,497 @@
+#
+msgid ""
+msgstr ""
+
+msgid ""
+"title: \"Local-First Software: You Own Your Data, in spite of the Cloud - "
+"article review\""
+msgstr ""
+
+msgid "date: 2020-11-14"
+msgstr ""
+
+msgid "layout: post"
+msgstr ""
+
+msgid "lang: en"
+msgstr ""
+
+msgid ""
+"ref: local-first-software-you-own-your-data-in-spite-of-the-cloud-article-"
+"review"
+msgstr ""
+
+msgid "eu_categories: presentation,article review"
+msgstr ""
+
+msgid ""
+"*This article is derived from a [presentation][presentation] given at a "
+"Papers We Love meetup on the same subject.*"
+msgstr ""
+
+msgid ""
+"This is a review of the article \"[Local-First Software: You Own Your Data, "
+"in spite of the Cloud][article-pdf]\", by M. Kleppmann, A. Wiggins, P. Van "
+"Hardenberg and M. F. McGranaghan."
+msgstr ""
+
+msgid "Offline-first, local-first"
+msgstr ""
+
+msgid ""
+"The \"local-first\" term they use isn't new, and I have used it myself in "
+"the past to refer to this types of application, where the data lives "
+"primarily on the client, and there are conflict resolution algorithms that "
+"reconcile data created on different instances."
+msgstr ""
+
+msgid ""
+"Sometimes I see confusion with this idea and \"client-side\", \"offline-"
+"friendly\", \"syncable\", etc. I have myself used this terms, also."
+msgstr ""
+
+msgid ""
+"There exists, however, already the \"offline-first\" term, which conveys "
+"almost all of that meaning. In my view, \"local-first\" doesn't extend "
+"\"offline-first\" in any aspect, rather it gives a well-defined meaning to "
+"it instead. I could say that \"local-first\" is just \"offline-first\", but "
+"with 7 well-defined ideals instead of community best practices."
+msgstr ""
+
+msgid ""
+"[presentation]: {% link _slides/2020-11-14-on-local-first-beyond-the-crdt-"
+"silver-bullet.slides %} [article-pdf]: "
+"https://martin.kleppmann.com/papers/local-first.pdf"
+msgstr ""
+
+msgid "Software licenses"
+msgstr ""
+
+msgid ""
+"On a footnote of the 7th ideal (\"You Retain Ultimate Ownership and "
+"Control\"), the authors say:"
+msgstr ""
+
+msgid ""
+"In our opinion, maintaining control and ownership of data does not mean that"
+" the software must necessarily be open source. (...) as long as it does not "
+"artificially restrict what users can do with their files."
+msgstr ""
+
+msgid ""
+"#!/bin/sh\n"
+"\n"
+"TODAY=$(date +%s)\n"
+"LICENSE_EXPIRATION=$(date -d 2020-11-15 +%s)\n"
+"\n"
+"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n"
+"  echo 'License expired!'\n"
+"  exit 1\n"
+"fi\n"
+"\n"
+"echo $((2 + 2))\n"
+msgstr ""
+
+msgid "Now when using this very useful program:"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ ./useful-adder.sh\n"
+"4\n"
+"# tomorrow\n"
+"$ ./useful-adder.sh\n"
+"License expired!\n"
+msgstr ""
+
+msgid ""
+"This is obviously an intentional restriction, and it goes against the 5th "
+"ideal (\"The Long Now\"). This software would only be useful as long as the "
+"embedded license expiration allowed. Sure you could change the clock on the "
+"computer, but there are many other ways that this type of intentional "
+"restriction is in conflict with that ideal."
+msgstr ""
+
+msgid ""
+"However, what about unintentional restrictions? What if a software had an "
+"equal or similar restriction, and stopped working after days pass? Or what "
+"if the programmer added a constant to make the development simpler, and this"
+" led to unintentionally restricting the user?"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ useful-program\n"
+"# ...useful output...\n"
+"\n"
+"# tomorrow, with more data\n"
+"$ useful-program\n"
+"ERROR: Panic! Stack overflow!\n"
+msgstr ""
+
+msgid ""
+"The point is: if the software isn't free/libre, \"The Long Now\" isn't "
+"achievable without a lot of wishful thinking. Maybe the authors were trying "
+"to be more friendly towards business who don't like FOSS, but in doing so "
+"they've proposed a contradiction by reconciling \"The Long Now\" with "
+"proprietary software."
+msgstr ""
+
+msgid ""
+"It isn't the same as saying that any free/libre software achieves that "
+"ideal, either. The license can still be free, but the source code can become"
+" unavailable due to cloud rot. Or maybe the build is undocumented, or the "
+"build tools had specific configuration that one has to guess. A piece of "
+"free/libre software can still fail to achieve \"The Long Now\". Being free "
+"doesn't guarantee it, just makes it possible."
+msgstr ""
+
+msgid ""
+"An open specification could serve as a blueprint to other implementations, "
+"making the data format more friendly to reverse-engineering. But the re-"
+"implementation still has to exist, at which point the original software "
+"failed to achieve \"The Long Now\"."
+msgstr ""
+
+msgid "It is less bad, but still not quite there yet."
+msgstr ""
+
+msgid "Denial of existing solutions"
+msgstr ""
+
+msgid ""
+"When describing \"Existing Data Storage and Sharing Models\", on a "
+"footnote[^devil] the authors say:"
+msgstr ""
+
+msgid ""
+"[^devil]: This is the second aspect that I'm picking on the article from a "
+"footnote. I guess the devil really is on the details."
+msgstr ""
+
+msgid ""
+"In principle it is possible to collaborate without a repository service, "
+"e.g. by sending patch files by email, but the majority of Git users rely on "
+"GitHub."
+msgstr ""
+
+msgid ""
+"The authors go to a great length to talk about usability of cloud apps, and "
+"even point to research they've done on it, but they've missed learning more "
+"from local-first solutions that already exist."
+msgstr ""
+
+msgid ""
+"Say the automerge CRDT proves to be even more useful than what everybody "
+"imagined. Say someone builds a local-first repository service using it. How "
+"will it change anything of the Git/GitHub model? What is different about it "
+"that prevents people in the future writing a paper saying:"
+msgstr ""
+
+msgid ""
+"In principle it is possible to collaborate without a repository service, "
+"e.g. by using automerge and platform X, but the majority of Git users rely "
+"on GitHub."
+msgstr ""
+
+msgid "How is this any better?"
+msgstr ""
+
+msgid ""
+"If it is already [possible](https://drewdevault.com/2018/07/23/Git-is-"
+"already-distributed.html) to have a local-first development workflow, why "
+"don't people use it? Is it just fashion, or there's a fundamental problem "
+"with it? If so, what is it, and how to avoid it?"
+msgstr ""
+
+msgid ""
+"If sending patches by emails is perfectly possible but out of fashion, why "
+"even talk about Git/GitHub? Isn't this a problem that people are putting "
+"themselves in? How can CRDTs possibly prevent people from doing that?"
+msgstr ""
+
+msgid ""
+"My impression is that the authors envision a better future, where "
+"development is fully decentralized unlike today, and somehow CRDTs will make"
+" that happen. If more people think this way, \"CRDT\" is next in line to the"
+" buzzword list that solves everything, like \"containers\", \"blockchain\" "
+"or \"machine learning\"."
+msgstr ""
+
+msgid ""
+"Rather than picturing an imaginary service that could be described like "
+"\"GitHub+CRDTs\" and people would adopt it, I'd rather better understand why"
+" people don't do it already, since Git is built to work like that."
+msgstr ""
+
+msgid "Ditching of web applications"
+msgstr ""
+
+msgid ""
+"The authors put web application in a worse position for building local-first"
+" application, claiming that:"
+msgstr ""
+
+msgid ""
+"(...) the architecture of web apps remains fundamentally server-centric. "
+"Offline support is an afterthought in most web apps, and the result is "
+"accordingly fragile."
+msgstr ""
+
+msgid "Well, I disagree."
+msgstr ""
+
+msgid ""
+"The problem isn't inherit to the web platform, but instead how people use "
+"it."
+msgstr ""
+
+msgid ""
+"I have myself built offline-first applications, leveraging IndexedDB, App "
+"Cache, *etc*. I wanted to build an offline-first application on the web, and"
+" so I did."
+msgstr ""
+
+msgid ""
+"In fact, many people choose [PouchDB](https://pouchdb.com/) *because* of "
+"that, since it is a good tool for offline-first web applications. The "
+"problem isn't really the technology, but how much people want their "
+"application to be local-first."
+msgstr ""
+
+msgid ""
+"Contrast it with Android [Instant "
+"Apps](https://developer.android.com/topic/google-play-instant), where "
+"applications are sent to the phone in small parts. Since this requires an "
+"internet connection to move from a part of the app bundle to another, a "
+"subset of the app isn't local-first, despite being an app."
+msgstr ""
+
+msgid ""
+"The point isn't the technology, but how people are using it. Local-first web"
+" applications are perfectly possible, just like non-local-first native "
+"applications are possible."
+msgstr ""
+
+msgid "Costs are underrated"
+msgstr ""
+
+msgid ""
+"I think the costs of \"old-fashioned apps\" over \"cloud apps\" are "
+"underrated, mainly regarding storage, and that this costs can vary a lot by "
+"application."
+msgstr ""
+
+msgid ""
+"Say a person writes online articles for their personal website, and puts "
+"everything into Git. Since there isn't supposed to be any collaboration, all"
+" of the relevant ideals of local-first are achieved."
+msgstr ""
+
+msgid ""
+"Now another person creates videos instead of articles. They could try "
+"keeping everything local, but after some time the storage usage fills the "
+"entire disk. This person's local-first setup would be much more complex, and"
+" would cost much more on maintenance, backup and storage."
+msgstr ""
+
+msgid ""
+"Even though both have similar needs, a local-first video repository is much "
+"more demanding. So the local-first thinking here isn't \"just keep "
+"everything local\", but \"how much time and money am I willing to spend to "
+"keep everything local\"."
+msgstr ""
+
+msgid ""
+"The convenience of \"cloud apps\" becomes so attractive that many don't even"
+" have a local copy of their videos, and rely exclusively on service "
+"providers to maintain, backup and store their content."
+msgstr ""
+
+msgid ""
+"The dial measuring \"cloud apps\" and \"old-fashioned apps\" needs to be "
+"specific to use-cases."
+msgstr ""
+
+msgid "Real-time collaboration is optional"
+msgstr ""
+
+msgid ""
+"If I were the one making the list of ideals, I wouldn't focus so much on "
+"real-time collaboration."
+msgstr ""
+
+msgid ""
+"Even though seamless collaboration is desired, it being real-time depends on"
+" the network being available for that. But ideal 3 states that \"The Network"
+" is Optional\", so real-time collaboration is also optional."
+msgstr ""
+
+msgid ""
+"The fundamentals of a local-first system should enable real-time "
+"collaboration when network is available, but shouldn't focus on it."
+msgstr ""
+
+msgid ""
+"On many places when discussing applications being offline, it is common for "
+"me to find people saying that their application works \"even on a plane, "
+"subway or elevator\". That is a reflection of when said developers have to "
+"deal with networks being unavailable."
+msgstr ""
+
+msgid ""
+"When discussing \"working offline\", I'd rather keep this type of person in "
+"mind, then the subset of people who are offline when on the elevator will "
+"naturally be included."
+msgstr ""
+
+msgid "On CRDTs and developer experience"
+msgstr ""
+
+msgid ""
+"When discussing developer experience, the authors bring up some questions to"
+" be answered further, like:"
+msgstr ""
+
+msgid ""
+"For an app developer, how does the use of a CRDT-based data layer compare to"
+" existing storage layers like a SQL database, a filesystem, or CoreData? Is "
+"a distributed system harder to write software for?"
+msgstr ""
+
+msgid "That is an easy one: yes."
+msgstr ""
+
+msgid ""
+"A distributed system *is* harder to write software for, being a distributed "
+"system."
+msgstr ""
+
+msgid "Conclusion"
+msgstr ""
+
+msgid ""
+"I liked a lot the article, as it took the \"offline-first\" philosophy and "
+"ran with it."
+msgstr ""
+
+msgid ""
+"But I think the authors' view of adding CRDTs and things becoming local-"
+"first is a bit too magical."
+msgstr ""
+
+msgid ""
+"It is a step forward, and given the number of times I've seen the paper "
+"shared around I think there's a chance people will prefer saying \"local-"
+"first\" in *lieu* of \"offline-first\" from now on."
+msgstr ""
+
+msgid ""
+"They give examples of artificial restrictions, like this artificial "
+"restriction I've come up with:"
+msgstr ""
+
+msgid ""
+"Just as easily as I can come up with ways to intentionally restrict users, I"
+" can do the same for unintentionally restrictions. A program can stop "
+"working for a variety of reasons."
+msgstr ""
+
+msgid ""
+"If it stops working due do, say, data growth, what are the options? "
+"Reverting to an earlier backup, and making it read-only? That isn't really a"
+" \"Long Now\", but rather a \"Long Now as long as the software keeps working"
+" as expected\"."
+msgstr ""
+
+msgid ""
+"A colleague has challenged my view, arguing that the software doesn't really"
+" need to be free, as long as there is an specification of the file format. "
+"This way if the software stops working, the format can still be processed by"
+" other programs. But this doesn't apply in practice: if you have a document "
+"that you write to, and software stops working, you still want to write to "
+"the document. An external tool that navigates the content and shows it to "
+"you won't allow you to keep writing, and when it does that tool is now "
+"starting to re-implement the software."
+msgstr ""
+
+msgid ""
+"But this leaves out a big chunk of the world where internet connection is "
+"intermittent, or only works every other day or only once a week, or stops "
+"working when it rains, *etc*. For this audience, living without network "
+"connectivity isn't such a discrete moment in time, but part of every day "
+"life. I like the fact that the authors acknowledge that."
+msgstr ""
+
+msgid ""
+"Adding a large layer of data structures and algorithms will make it more "
+"complex to write software for, naturally. And if trying to make this layer "
+"transparent to the programmer, so they can pretend that layer doesn't exist "
+"is a bad idea, as RPC frameworks have tried, and failed."
+msgstr ""
+
+msgid ""
+"See \"[A Note on Distributed "
+"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\""
+" for a critique on RPC frameworks trying to make the network invisible, "
+"which I think also applies in equivalence for making the CRDTs layer "
+"invisible."
+msgstr ""
+
+msgid ""
+"This particular area is one that I have large interest on, and I wish to see"
+" more being done on the \"local-first\" space."
+msgstr ""
+
+#~ msgid "They give examples of artificial restrictions, like this one:"
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Just as easily as I can come up with ways to intentionally restrict users, "
+#~ "just as easily I can do the same for unintentionally restricting users. A "
+#~ "program can stop working for a variety of reasons."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "If it stops working due do data growth, what are the options? Reverting to "
+#~ "an earlier backup, and making it read-only? That isn't really a \"Long "
+#~ "Now\", but rather a \"Long Now as long as the software keeps working as "
+#~ "expected\"."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "A colleague has challenged my view, arguing that the software doesn't really"
+#~ " need to be free, as long as there is an specification of the file format. "
+#~ "This way is the software stops working, the format can still be processed by"
+#~ " other programs. But this doesn't apply in practice: if you have a document "
+#~ "that you write to, and software stops working, you still want to write to "
+#~ "the document. An external tool that navigates the content and shows it to "
+#~ "you won't allow you to keep writing, and when it does that tool is now "
+#~ "starting to re-implement the software."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "But this leaves out a big chunk of the world where internet connection is "
+#~ "intermittent, or only work every other day or only once a week, or stops "
+#~ "working when it rains, *etc*. For this audience, living without network "
+#~ "connectivity isn't such a discrete moment in time, but part of every day "
+#~ "life. I like the fact that the authors acknowledge that."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Adding a large layer of data structures and algorithms will make it more "
+#~ "complex to write software for, naturally. And if trying to make this layer "
+#~ "transparent to the programmer, so they can pretend that layer doesn't exist "
+#~ "is a bad idea, as RPC frameworks have tried, and failed. See \"[A Note on "
+#~ "Distributed "
+#~ "Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\""
+#~ " for a critique on RPC frameworks trying to make the network invisible, "
+#~ "which I think also applies in equivalence for making the CRDTs layer "
+#~ "invisible."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "It is a step forward, and given the number of times I've seen the paper "
+#~ "shared around I think there's a chance people will prefer saying \"local-"
+#~ "first\" in lieu of \"offline-first\" from now on."
+#~ msgstr ""
diff --git a/locale/fr/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po b/locale/fr/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po
new file mode 100644
index 0000000..7674704
--- /dev/null
+++ b/locale/fr/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po
@@ -0,0 +1,322 @@
+#
+msgid ""
+msgstr ""
+
+msgid "title: 'On \"local-first\": beyond the CRDT silver bullet'"
+msgstr ""
+
+msgid "date: 2020-11-14"
+msgstr ""
+
+msgid "layout: slides"
+msgstr ""
+
+msgid "lang: en"
+msgstr ""
+
+msgid "ref: on-local-first-beyond-the-crdt-silver-bullet"
+msgstr ""
+
+msgid "On local-first"
+msgstr ""
+
+msgid "Beyond the CRDT silver bullet"
+msgstr ""
+
+msgid "Part 1"
+msgstr ""
+
+msgid "Exposition"
+msgstr ""
+
+msgid "\"cloud apps\" vs \"old-fashioned apps\""
+msgstr ""
+
+msgid "Target"
+msgstr ""
+
+msgid "documents"
+msgstr ""
+
+msgid "files"
+msgstr ""
+
+msgid "personal data repositories"
+msgstr ""
+
+msgid ""
+"Not: banking services, e-commerce, social networking, ride-sharing, *etc*."
+msgstr ""
+
+msgid "7 Ideals for local-first software"
+msgstr ""
+
+msgid "1 - No Spinners: Your Work at Your Fingertips"
+msgstr ""
+
+msgid "2 - Your Work Is Not Trapped on One Device"
+msgstr ""
+
+msgid "3 - The Network Is Optional"
+msgstr ""
+
+msgid "4 - Seamless Collaboration with Your Colleagues"
+msgstr ""
+
+msgid "5 - The Long Now"
+msgstr ""
+
+msgid "6 - Security and Privacy by Default"
+msgstr ""
+
+msgid "7 - You Retain Ultimate Ownership and Control"
+msgstr ""
+
+msgid "Towards a Better Future"
+msgstr ""
+
+msgid ""
+"CRDTs (Conflict-free Replicated Data Types) as a Foundational Technology"
+msgstr ""
+
+msgid "Use case"
+msgstr ""
+
+msgid ""
+"# in node A and node B\n"
+"s = \"Hello, World\"\n"
+"\n"
+"# in node A\n"
+"s = \"Hello, Alice\"\n"
+"\n"
+"# in node B\n"
+"s = \"Hello, Bob\"\n"
+msgstr ""
+
+msgid "How to reconcile those?"
+msgstr ""
+
+msgid "`Hello, ABloibce`"
+msgstr ""
+
+msgid "`Hello, AliceBob`"
+msgstr ""
+
+msgid "`Hello, BobAlice`"
+msgstr ""
+
+msgid "`Hello, Alice`"
+msgstr ""
+
+msgid "`Hello, Bob`"
+msgstr ""
+
+msgid "Existing CRDTs differ:"
+msgstr ""
+
+msgid "performance"
+msgstr ""
+
+msgid "storage"
+msgstr ""
+
+msgid "compression"
+msgstr ""
+
+msgid "metadata overhead"
+msgstr ""
+
+msgid "Hint towards the \"automerge\" CRDT"
+msgstr ""
+
+msgid "*show comparison table, page 9*"
+msgstr ""
+
+msgid "Part 2"
+msgstr ""
+
+msgid "Critique"
+msgstr ""
+
+msgid "Software license"
+msgstr ""
+
+msgid ""
+"In our opinion, maintaining control and ownership of data does not mean that"
+" the software must necessarily be open source."
+msgstr ""
+
+msgid "Example 1 - intentional restriction"
+msgstr ""
+
+msgid ""
+"#!/bin/sh\n"
+"\n"
+"TODAY=$(date +%s)\n"
+"LICENSE_EXPIRATION=$(date -d 2020-10-27 +%s)\n"
+"\n"
+"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n"
+"  echo 'License expired!'\n"
+"  exit 1\n"
+"fi\n"
+"\n"
+"echo $((2 + 2))\n"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ ./useful-adder.sh\n"
+"4\n"
+"# tomorrow\n"
+"$ ./useful-adder.sh\n"
+"License expired!\n"
+msgstr ""
+
+msgid "Example 2 - unintentional restriction"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ useful-program\n"
+"# ...useful output...\n"
+"\n"
+"# tomorrow, with more data\n"
+"$ useful-program\n"
+"ERROR: Panic! Stack overflow!\n"
+msgstr ""
+
+msgid "local-first **requires** free/libre software"
+msgstr ""
+
+msgid "Otherwise \"The Long Now\" (ideal nº5) is lost"
+msgstr ""
+
+msgid "Denial of existing solutions"
+msgstr ""
+
+msgid ""
+"In principle it is possible to collaborate without a repository service, "
+"e.g. by sending patch files by email, but the majority of Git users rely on "
+"GitHub."
+msgstr ""
+
+msgid "Solution: either GitHub+CRDTs or `git` **`send-email`**"
+msgstr ""
+
+msgid "Plain text formats"
+msgstr ""
+
+msgid "Git is highly optimized for code and similar line-based text file"
+msgstr ""
+
+msgid "It even pulls software to the plain text direction, e.g.:"
+msgstr ""
+
+msgid "delivery-templates"
+msgstr ""
+
+msgid "`common-core.protocols.config`"
+msgstr ""
+
+msgid "Why not exploit that more?"
+msgstr ""
+
+msgid "Ditching of web applications"
+msgstr ""
+
+msgid "The architecture of web apps remains fundamentally server-centric"
+msgstr ""
+
+msgid ""
+"Disagree. Contrast [PouchDB](https://pouchdb.com/) with Android [Instant "
+"Apps](https://developer.android.com/topic/google-play-instant)"
+msgstr ""
+
+msgid "???"
+msgstr ""
+
+msgid "Talk on dynamic content"
+msgstr ""
+
+msgid "Costs are underrated"
+msgstr ""
+
+msgid "backups"
+msgstr ""
+
+msgid "maintenance"
+msgstr ""
+
+msgid "Example: blog vs vlog"
+msgstr ""
+
+msgid "Real-time collaboration a bit overrated"
+msgstr ""
+
+msgid ""
+"It is only possible on the presence of reliable, medium-quality network "
+"connection"
+msgstr ""
+
+msgid "X also works when inside an elevator, subway or plane!"
+msgstr ""
+
+msgid "On CRDTs and developer experience"
+msgstr ""
+
+msgid ""
+"For an app developer, how does the use of a CRDT-based data layer compare to"
+" existing storage layers like a SQL database, a filesystem, or CoreData? Is "
+"a distributed system harder to write software for?"
+msgstr ""
+
+msgid "Yes."
+msgstr ""
+
+msgid ""
+"See \"[A Note on Distributed "
+"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\""
+msgstr ""
+
+msgid "Conclusion"
+msgstr ""
+
+msgid "Why this is a \"paper I love\": it took offline-first and ran with it."
+msgstr ""
+
+msgid "But a pinch of CRDT won't make the world local-first."
+msgstr ""
+
+msgid "The tricky part is the end of the sentence: \"**in spite of the Cloud**\"."
+msgstr ""
+
+msgid "Thank you!"
+msgstr ""
+
+msgid "References:"
+msgstr ""
+
+msgid "these slides: [{{ site.tld }}/slides.html]({% link slides.md %})"
+msgstr ""
+
+msgid ""
+"[prose version of this presentation]({% link _articles/2020-11-14-local-"
+"first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %})"
+msgstr ""
+
+msgid ""
+"\"[Local-First Software: You Own Your Data, in spite of the "
+"Cloud](https://martin.kleppmann.com/papers/local-first.pdf)\", by M. "
+"Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan"
+msgstr ""
+
+msgid ""
+"[The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-"
+"software/) article"
+msgstr ""
+
+msgid ""
+"\"[A Note on Distributed "
+"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\","
+" by J. Waldo, G. Wyant, A. Wollrath and S Kendall"
+msgstr ""
diff --git a/locale/pt/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po b/locale/pt/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po
new file mode 100644
index 0000000..ade1529
--- /dev/null
+++ b/locale/pt/LC_MESSAGES/_articles/2020-11-14-local-first-software-you-own-your-data-in-spite-of-the-cloud-article-review.po
@@ -0,0 +1,497 @@
+#
+msgid ""
+msgstr ""
+
+msgid ""
+"title: \"Local-First Software: You Own Your Data, in spite of the Cloud - "
+"article review\""
+msgstr ""
+
+msgid "date: 2020-11-14"
+msgstr ""
+
+msgid "layout: post"
+msgstr ""
+
+msgid "lang: en"
+msgstr ""
+
+msgid ""
+"ref: local-first-software-you-own-your-data-in-spite-of-the-cloud-article-"
+"review"
+msgstr ""
+
+msgid "eu_categories: presentation,article review"
+msgstr ""
+
+msgid ""
+"*This article is derived from a [presentation][presentation] given at a "
+"Papers We Love meetup on the same subject.*"
+msgstr ""
+
+msgid ""
+"This is a review of the article \"[Local-First Software: You Own Your Data, "
+"in spite of the Cloud][article-pdf]\", by M. Kleppmann, A. Wiggins, P. Van "
+"Hardenberg and M. F. McGranaghan."
+msgstr ""
+
+msgid "Offline-first, local-first"
+msgstr ""
+
+msgid ""
+"The \"local-first\" term they use isn't new, and I have used it myself in "
+"the past to refer to this types of application, where the data lives "
+"primarily on the client, and there are conflict resolution algorithms that "
+"reconcile data created on different instances."
+msgstr ""
+
+msgid ""
+"Sometimes I see confusion with this idea and \"client-side\", \"offline-"
+"friendly\", \"syncable\", etc. I have myself used this terms, also."
+msgstr ""
+
+msgid ""
+"There exists, however, already the \"offline-first\" term, which conveys "
+"almost all of that meaning. In my view, \"local-first\" doesn't extend "
+"\"offline-first\" in any aspect, rather it gives a well-defined meaning to "
+"it instead. I could say that \"local-first\" is just \"offline-first\", but "
+"with 7 well-defined ideals instead of community best practices."
+msgstr ""
+
+msgid ""
+"[presentation]: {% link _slides/2020-11-14-on-local-first-beyond-the-crdt-"
+"silver-bullet.slides %} [article-pdf]: "
+"https://martin.kleppmann.com/papers/local-first.pdf"
+msgstr ""
+
+msgid "Software licenses"
+msgstr ""
+
+msgid ""
+"On a footnote of the 7th ideal (\"You Retain Ultimate Ownership and "
+"Control\"), the authors say:"
+msgstr ""
+
+msgid ""
+"In our opinion, maintaining control and ownership of data does not mean that"
+" the software must necessarily be open source. (...) as long as it does not "
+"artificially restrict what users can do with their files."
+msgstr ""
+
+msgid ""
+"#!/bin/sh\n"
+"\n"
+"TODAY=$(date +%s)\n"
+"LICENSE_EXPIRATION=$(date -d 2020-11-15 +%s)\n"
+"\n"
+"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n"
+"  echo 'License expired!'\n"
+"  exit 1\n"
+"fi\n"
+"\n"
+"echo $((2 + 2))\n"
+msgstr ""
+
+msgid "Now when using this very useful program:"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ ./useful-adder.sh\n"
+"4\n"
+"# tomorrow\n"
+"$ ./useful-adder.sh\n"
+"License expired!\n"
+msgstr ""
+
+msgid ""
+"This is obviously an intentional restriction, and it goes against the 5th "
+"ideal (\"The Long Now\"). This software would only be useful as long as the "
+"embedded license expiration allowed. Sure you could change the clock on the "
+"computer, but there are many other ways that this type of intentional "
+"restriction is in conflict with that ideal."
+msgstr ""
+
+msgid ""
+"However, what about unintentional restrictions? What if a software had an "
+"equal or similar restriction, and stopped working after days pass? Or what "
+"if the programmer added a constant to make the development simpler, and this"
+" led to unintentionally restricting the user?"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ useful-program\n"
+"# ...useful output...\n"
+"\n"
+"# tomorrow, with more data\n"
+"$ useful-program\n"
+"ERROR: Panic! Stack overflow!\n"
+msgstr ""
+
+msgid ""
+"The point is: if the software isn't free/libre, \"The Long Now\" isn't "
+"achievable without a lot of wishful thinking. Maybe the authors were trying "
+"to be more friendly towards business who don't like FOSS, but in doing so "
+"they've proposed a contradiction by reconciling \"The Long Now\" with "
+"proprietary software."
+msgstr ""
+
+msgid ""
+"It isn't the same as saying that any free/libre software achieves that "
+"ideal, either. The license can still be free, but the source code can become"
+" unavailable due to cloud rot. Or maybe the build is undocumented, or the "
+"build tools had specific configuration that one has to guess. A piece of "
+"free/libre software can still fail to achieve \"The Long Now\". Being free "
+"doesn't guarantee it, just makes it possible."
+msgstr ""
+
+msgid ""
+"An open specification could serve as a blueprint to other implementations, "
+"making the data format more friendly to reverse-engineering. But the re-"
+"implementation still has to exist, at which point the original software "
+"failed to achieve \"The Long Now\"."
+msgstr ""
+
+msgid "It is less bad, but still not quite there yet."
+msgstr ""
+
+msgid "Denial of existing solutions"
+msgstr ""
+
+msgid ""
+"When describing \"Existing Data Storage and Sharing Models\", on a "
+"footnote[^devil] the authors say:"
+msgstr ""
+
+msgid ""
+"[^devil]: This is the second aspect that I'm picking on the article from a "
+"footnote. I guess the devil really is on the details."
+msgstr ""
+
+msgid ""
+"In principle it is possible to collaborate without a repository service, "
+"e.g. by sending patch files by email, but the majority of Git users rely on "
+"GitHub."
+msgstr ""
+
+msgid ""
+"The authors go to a great length to talk about usability of cloud apps, and "
+"even point to research they've done on it, but they've missed learning more "
+"from local-first solutions that already exist."
+msgstr ""
+
+msgid ""
+"Say the automerge CRDT proves to be even more useful than what everybody "
+"imagined. Say someone builds a local-first repository service using it. How "
+"will it change anything of the Git/GitHub model? What is different about it "
+"that prevents people in the future writing a paper saying:"
+msgstr ""
+
+msgid ""
+"In principle it is possible to collaborate without a repository service, "
+"e.g. by using automerge and platform X, but the majority of Git users rely "
+"on GitHub."
+msgstr ""
+
+msgid "How is this any better?"
+msgstr ""
+
+msgid ""
+"If it is already [possible](https://drewdevault.com/2018/07/23/Git-is-"
+"already-distributed.html) to have a local-first development workflow, why "
+"don't people use it? Is it just fashion, or there's a fundamental problem "
+"with it? If so, what is it, and how to avoid it?"
+msgstr ""
+
+msgid ""
+"If sending patches by emails is perfectly possible but out of fashion, why "
+"even talk about Git/GitHub? Isn't this a problem that people are putting "
+"themselves in? How can CRDTs possibly prevent people from doing that?"
+msgstr ""
+
+msgid ""
+"My impression is that the authors envision a better future, where "
+"development is fully decentralized unlike today, and somehow CRDTs will make"
+" that happen. If more people think this way, \"CRDT\" is next in line to the"
+" buzzword list that solves everything, like \"containers\", \"blockchain\" "
+"or \"machine learning\"."
+msgstr ""
+
+msgid ""
+"Rather than picturing an imaginary service that could be described like "
+"\"GitHub+CRDTs\" and people would adopt it, I'd rather better understand why"
+" people don't do it already, since Git is built to work like that."
+msgstr ""
+
+msgid "Ditching of web applications"
+msgstr ""
+
+msgid ""
+"The authors put web application in a worse position for building local-first"
+" application, claiming that:"
+msgstr ""
+
+msgid ""
+"(...) the architecture of web apps remains fundamentally server-centric. "
+"Offline support is an afterthought in most web apps, and the result is "
+"accordingly fragile."
+msgstr ""
+
+msgid "Well, I disagree."
+msgstr ""
+
+msgid ""
+"The problem isn't inherit to the web platform, but instead how people use "
+"it."
+msgstr ""
+
+msgid ""
+"I have myself built offline-first applications, leveraging IndexedDB, App "
+"Cache, *etc*. I wanted to build an offline-first application on the web, and"
+" so I did."
+msgstr ""
+
+msgid ""
+"In fact, many people choose [PouchDB](https://pouchdb.com/) *because* of "
+"that, since it is a good tool for offline-first web applications. The "
+"problem isn't really the technology, but how much people want their "
+"application to be local-first."
+msgstr ""
+
+msgid ""
+"Contrast it with Android [Instant "
+"Apps](https://developer.android.com/topic/google-play-instant), where "
+"applications are sent to the phone in small parts. Since this requires an "
+"internet connection to move from a part of the app bundle to another, a "
+"subset of the app isn't local-first, despite being an app."
+msgstr ""
+
+msgid ""
+"The point isn't the technology, but how people are using it. Local-first web"
+" applications are perfectly possible, just like non-local-first native "
+"applications are possible."
+msgstr ""
+
+msgid "Costs are underrated"
+msgstr ""
+
+msgid ""
+"I think the costs of \"old-fashioned apps\" over \"cloud apps\" are "
+"underrated, mainly regarding storage, and that this costs can vary a lot by "
+"application."
+msgstr ""
+
+msgid ""
+"Say a person writes online articles for their personal website, and puts "
+"everything into Git. Since there isn't supposed to be any collaboration, all"
+" of the relevant ideals of local-first are achieved."
+msgstr ""
+
+msgid ""
+"Now another person creates videos instead of articles. They could try "
+"keeping everything local, but after some time the storage usage fills the "
+"entire disk. This person's local-first setup would be much more complex, and"
+" would cost much more on maintenance, backup and storage."
+msgstr ""
+
+msgid ""
+"Even though both have similar needs, a local-first video repository is much "
+"more demanding. So the local-first thinking here isn't \"just keep "
+"everything local\", but \"how much time and money am I willing to spend to "
+"keep everything local\"."
+msgstr ""
+
+msgid ""
+"The convenience of \"cloud apps\" becomes so attractive that many don't even"
+" have a local copy of their videos, and rely exclusively on service "
+"providers to maintain, backup and store their content."
+msgstr ""
+
+msgid ""
+"The dial measuring \"cloud apps\" and \"old-fashioned apps\" needs to be "
+"specific to use-cases."
+msgstr ""
+
+msgid "Real-time collaboration is optional"
+msgstr ""
+
+msgid ""
+"If I were the one making the list of ideals, I wouldn't focus so much on "
+"real-time collaboration."
+msgstr ""
+
+msgid ""
+"Even though seamless collaboration is desired, it being real-time depends on"
+" the network being available for that. But ideal 3 states that \"The Network"
+" is Optional\", so real-time collaboration is also optional."
+msgstr ""
+
+msgid ""
+"The fundamentals of a local-first system should enable real-time "
+"collaboration when network is available, but shouldn't focus on it."
+msgstr ""
+
+msgid ""
+"On many places when discussing applications being offline, it is common for "
+"me to find people saying that their application works \"even on a plane, "
+"subway or elevator\". That is a reflection of when said developers have to "
+"deal with networks being unavailable."
+msgstr ""
+
+msgid ""
+"When discussing \"working offline\", I'd rather keep this type of person in "
+"mind, then the subset of people who are offline when on the elevator will "
+"naturally be included."
+msgstr ""
+
+msgid "On CRDTs and developer experience"
+msgstr ""
+
+msgid ""
+"When discussing developer experience, the authors bring up some questions to"
+" be answered further, like:"
+msgstr ""
+
+msgid ""
+"For an app developer, how does the use of a CRDT-based data layer compare to"
+" existing storage layers like a SQL database, a filesystem, or CoreData? Is "
+"a distributed system harder to write software for?"
+msgstr ""
+
+msgid "That is an easy one: yes."
+msgstr ""
+
+msgid ""
+"A distributed system *is* harder to write software for, being a distributed "
+"system."
+msgstr ""
+
+msgid "Conclusion"
+msgstr ""
+
+msgid ""
+"I liked a lot the article, as it took the \"offline-first\" philosophy and "
+"ran with it."
+msgstr ""
+
+msgid ""
+"But I think the authors' view of adding CRDTs and things becoming local-"
+"first is a bit too magical."
+msgstr ""
+
+msgid ""
+"It is a step forward, and given the number of times I've seen the paper "
+"shared around I think there's a chance people will prefer saying \"local-"
+"first\" in *lieu* of \"offline-first\" from now on."
+msgstr ""
+
+msgid ""
+"They give examples of artificial restrictions, like this artificial "
+"restriction I've come up with:"
+msgstr ""
+
+msgid ""
+"Just as easily as I can come up with ways to intentionally restrict users, I"
+" can do the same for unintentionally restrictions. A program can stop "
+"working for a variety of reasons."
+msgstr ""
+
+msgid ""
+"If it stops working due do, say, data growth, what are the options? "
+"Reverting to an earlier backup, and making it read-only? That isn't really a"
+" \"Long Now\", but rather a \"Long Now as long as the software keeps working"
+" as expected\"."
+msgstr ""
+
+msgid ""
+"A colleague has challenged my view, arguing that the software doesn't really"
+" need to be free, as long as there is an specification of the file format. "
+"This way if the software stops working, the format can still be processed by"
+" other programs. But this doesn't apply in practice: if you have a document "
+"that you write to, and software stops working, you still want to write to "
+"the document. An external tool that navigates the content and shows it to "
+"you won't allow you to keep writing, and when it does that tool is now "
+"starting to re-implement the software."
+msgstr ""
+
+msgid ""
+"But this leaves out a big chunk of the world where internet connection is "
+"intermittent, or only works every other day or only once a week, or stops "
+"working when it rains, *etc*. For this audience, living without network "
+"connectivity isn't such a discrete moment in time, but part of every day "
+"life. I like the fact that the authors acknowledge that."
+msgstr ""
+
+msgid ""
+"Adding a large layer of data structures and algorithms will make it more "
+"complex to write software for, naturally. And if trying to make this layer "
+"transparent to the programmer, so they can pretend that layer doesn't exist "
+"is a bad idea, as RPC frameworks have tried, and failed."
+msgstr ""
+
+msgid ""
+"See \"[A Note on Distributed "
+"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\""
+" for a critique on RPC frameworks trying to make the network invisible, "
+"which I think also applies in equivalence for making the CRDTs layer "
+"invisible."
+msgstr ""
+
+msgid ""
+"This particular area is one that I have large interest on, and I wish to see"
+" more being done on the \"local-first\" space."
+msgstr ""
+
+#~ msgid "They give examples of artificial restrictions, like this one:"
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Just as easily as I can come up with ways to intentionally restrict users, "
+#~ "just as easily I can do the same for unintentionally restricting users. A "
+#~ "program can stop working for a variety of reasons."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "If it stops working due do data growth, what are the options? Reverting to "
+#~ "an earlier backup, and making it read-only? That isn't really a \"Long "
+#~ "Now\", but rather a \"Long Now as long as the software keeps working as "
+#~ "expected\"."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "A colleague has challenged my view, arguing that the software doesn't really"
+#~ " need to be free, as long as there is an specification of the file format. "
+#~ "This way is the software stops working, the format can still be processed by"
+#~ " other programs. But this doesn't apply in practice: if you have a document "
+#~ "that you write to, and software stops working, you still want to write to "
+#~ "the document. An external tool that navigates the content and shows it to "
+#~ "you won't allow you to keep writing, and when it does that tool is now "
+#~ "starting to re-implement the software."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "But this leaves out a big chunk of the world where internet connection is "
+#~ "intermittent, or only work every other day or only once a week, or stops "
+#~ "working when it rains, *etc*. For this audience, living without network "
+#~ "connectivity isn't such a discrete moment in time, but part of every day "
+#~ "life. I like the fact that the authors acknowledge that."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "Adding a large layer of data structures and algorithms will make it more "
+#~ "complex to write software for, naturally. And if trying to make this layer "
+#~ "transparent to the programmer, so they can pretend that layer doesn't exist "
+#~ "is a bad idea, as RPC frameworks have tried, and failed. See \"[A Note on "
+#~ "Distributed "
+#~ "Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\""
+#~ " for a critique on RPC frameworks trying to make the network invisible, "
+#~ "which I think also applies in equivalence for making the CRDTs layer "
+#~ "invisible."
+#~ msgstr ""
+
+#~ msgid ""
+#~ "It is a step forward, and given the number of times I've seen the paper "
+#~ "shared around I think there's a chance people will prefer saying \"local-"
+#~ "first\" in lieu of \"offline-first\" from now on."
+#~ msgstr ""
diff --git a/locale/pt/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po b/locale/pt/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po
new file mode 100644
index 0000000..7674704
--- /dev/null
+++ b/locale/pt/LC_MESSAGES/_slides/2020-11-14-on-local-first-beyond-the-crdt-silver-bullet.slides.po
@@ -0,0 +1,322 @@
+#
+msgid ""
+msgstr ""
+
+msgid "title: 'On \"local-first\": beyond the CRDT silver bullet'"
+msgstr ""
+
+msgid "date: 2020-11-14"
+msgstr ""
+
+msgid "layout: slides"
+msgstr ""
+
+msgid "lang: en"
+msgstr ""
+
+msgid "ref: on-local-first-beyond-the-crdt-silver-bullet"
+msgstr ""
+
+msgid "On local-first"
+msgstr ""
+
+msgid "Beyond the CRDT silver bullet"
+msgstr ""
+
+msgid "Part 1"
+msgstr ""
+
+msgid "Exposition"
+msgstr ""
+
+msgid "\"cloud apps\" vs \"old-fashioned apps\""
+msgstr ""
+
+msgid "Target"
+msgstr ""
+
+msgid "documents"
+msgstr ""
+
+msgid "files"
+msgstr ""
+
+msgid "personal data repositories"
+msgstr ""
+
+msgid ""
+"Not: banking services, e-commerce, social networking, ride-sharing, *etc*."
+msgstr ""
+
+msgid "7 Ideals for local-first software"
+msgstr ""
+
+msgid "1 - No Spinners: Your Work at Your Fingertips"
+msgstr ""
+
+msgid "2 - Your Work Is Not Trapped on One Device"
+msgstr ""
+
+msgid "3 - The Network Is Optional"
+msgstr ""
+
+msgid "4 - Seamless Collaboration with Your Colleagues"
+msgstr ""
+
+msgid "5 - The Long Now"
+msgstr ""
+
+msgid "6 - Security and Privacy by Default"
+msgstr ""
+
+msgid "7 - You Retain Ultimate Ownership and Control"
+msgstr ""
+
+msgid "Towards a Better Future"
+msgstr ""
+
+msgid ""
+"CRDTs (Conflict-free Replicated Data Types) as a Foundational Technology"
+msgstr ""
+
+msgid "Use case"
+msgstr ""
+
+msgid ""
+"# in node A and node B\n"
+"s = \"Hello, World\"\n"
+"\n"
+"# in node A\n"
+"s = \"Hello, Alice\"\n"
+"\n"
+"# in node B\n"
+"s = \"Hello, Bob\"\n"
+msgstr ""
+
+msgid "How to reconcile those?"
+msgstr ""
+
+msgid "`Hello, ABloibce`"
+msgstr ""
+
+msgid "`Hello, AliceBob`"
+msgstr ""
+
+msgid "`Hello, BobAlice`"
+msgstr ""
+
+msgid "`Hello, Alice`"
+msgstr ""
+
+msgid "`Hello, Bob`"
+msgstr ""
+
+msgid "Existing CRDTs differ:"
+msgstr ""
+
+msgid "performance"
+msgstr ""
+
+msgid "storage"
+msgstr ""
+
+msgid "compression"
+msgstr ""
+
+msgid "metadata overhead"
+msgstr ""
+
+msgid "Hint towards the \"automerge\" CRDT"
+msgstr ""
+
+msgid "*show comparison table, page 9*"
+msgstr ""
+
+msgid "Part 2"
+msgstr ""
+
+msgid "Critique"
+msgstr ""
+
+msgid "Software license"
+msgstr ""
+
+msgid ""
+"In our opinion, maintaining control and ownership of data does not mean that"
+" the software must necessarily be open source."
+msgstr ""
+
+msgid "Example 1 - intentional restriction"
+msgstr ""
+
+msgid ""
+"#!/bin/sh\n"
+"\n"
+"TODAY=$(date +%s)\n"
+"LICENSE_EXPIRATION=$(date -d 2020-10-27 +%s)\n"
+"\n"
+"if [ $TODAY -ge $LICENSE_EXPIRATION ]; then\n"
+"  echo 'License expired!'\n"
+"  exit 1\n"
+"fi\n"
+"\n"
+"echo $((2 + 2))\n"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ ./useful-adder.sh\n"
+"4\n"
+"# tomorrow\n"
+"$ ./useful-adder.sh\n"
+"License expired!\n"
+msgstr ""
+
+msgid "Example 2 - unintentional restriction"
+msgstr ""
+
+msgid ""
+"# today\n"
+"$ useful-program\n"
+"# ...useful output...\n"
+"\n"
+"# tomorrow, with more data\n"
+"$ useful-program\n"
+"ERROR: Panic! Stack overflow!\n"
+msgstr ""
+
+msgid "local-first **requires** free/libre software"
+msgstr ""
+
+msgid "Otherwise \"The Long Now\" (ideal nº5) is lost"
+msgstr ""
+
+msgid "Denial of existing solutions"
+msgstr ""
+
+msgid ""
+"In principle it is possible to collaborate without a repository service, "
+"e.g. by sending patch files by email, but the majority of Git users rely on "
+"GitHub."
+msgstr ""
+
+msgid "Solution: either GitHub+CRDTs or `git` **`send-email`**"
+msgstr ""
+
+msgid "Plain text formats"
+msgstr ""
+
+msgid "Git is highly optimized for code and similar line-based text file"
+msgstr ""
+
+msgid "It even pulls software to the plain text direction, e.g.:"
+msgstr ""
+
+msgid "delivery-templates"
+msgstr ""
+
+msgid "`common-core.protocols.config`"
+msgstr ""
+
+msgid "Why not exploit that more?"
+msgstr ""
+
+msgid "Ditching of web applications"
+msgstr ""
+
+msgid "The architecture of web apps remains fundamentally server-centric"
+msgstr ""
+
+msgid ""
+"Disagree. Contrast [PouchDB](https://pouchdb.com/) with Android [Instant "
+"Apps](https://developer.android.com/topic/google-play-instant)"
+msgstr ""
+
+msgid "???"
+msgstr ""
+
+msgid "Talk on dynamic content"
+msgstr ""
+
+msgid "Costs are underrated"
+msgstr ""
+
+msgid "backups"
+msgstr ""
+
+msgid "maintenance"
+msgstr ""
+
+msgid "Example: blog vs vlog"
+msgstr ""
+
+msgid "Real-time collaboration a bit overrated"
+msgstr ""
+
+msgid ""
+"It is only possible on the presence of reliable, medium-quality network "
+"connection"
+msgstr ""
+
+msgid "X also works when inside an elevator, subway or plane!"
+msgstr ""
+
+msgid "On CRDTs and developer experience"
+msgstr ""
+
+msgid ""
+"For an app developer, how does the use of a CRDT-based data layer compare to"
+" existing storage layers like a SQL database, a filesystem, or CoreData? Is "
+"a distributed system harder to write software for?"
+msgstr ""
+
+msgid "Yes."
+msgstr ""
+
+msgid ""
+"See \"[A Note on Distributed "
+"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\""
+msgstr ""
+
+msgid "Conclusion"
+msgstr ""
+
+msgid "Why this is a \"paper I love\": it took offline-first and ran with it."
+msgstr ""
+
+msgid "But a pinch of CRDT won't make the world local-first."
+msgstr ""
+
+msgid "The tricky part is the end of the sentence: \"**in spite of the Cloud**\"."
+msgstr ""
+
+msgid "Thank you!"
+msgstr ""
+
+msgid "References:"
+msgstr ""
+
+msgid "these slides: [{{ site.tld }}/slides.html]({% link slides.md %})"
+msgstr ""
+
+msgid ""
+"[prose version of this presentation]({% link _articles/2020-11-14-local-"
+"first-software-you-own-your-data-in-spite-of-the-cloud-article-review.md %})"
+msgstr ""
+
+msgid ""
+"\"[Local-First Software: You Own Your Data, in spite of the "
+"Cloud](https://martin.kleppmann.com/papers/local-first.pdf)\", by M. "
+"Kleppmann, A. Wiggins, P. Van Hardenberg and M. F. McGranaghan"
+msgstr ""
+
+msgid ""
+"[The Morning Paper](https://blog.acolyer.org/2019/11/20/local-first-"
+"software/) article"
+msgstr ""
+
+msgid ""
+"\"[A Note on Distributed "
+"Computing](https://web.archive.org/web/20130116163535/http://labs.oracle.com/techrep/1994/smli_tr-94-29.pdf)\","
+" by J. Waldo, G. Wyant, A. Wollrath and S Kendall"
+msgstr ""
diff --git a/scripts/spelling/en.txt b/scripts/spelling/en.txt
index 98a0351..939e182 100644
--- a/scripts/spelling/en.txt
+++ b/scripts/spelling/en.txt
@@ -9,8 +9,10 @@ backend
 balancer
 barcode
 behaviour
+centric
 chargeback
 combinators
+config
 couldn
 cronjobs
 culting
diff --git a/scripts/spelling/international.txt b/scripts/spelling/international.txt
index dc9b90e..8b6488a 100644
--- a/scripts/spelling/international.txt
+++ b/scripts/spelling/international.txt
@@ -7,8 +7,10 @@
 500GB
 81F90EC3CD356060
 8GB
+ABloibce
 AGPLv
 AGPLv3
+AliceBob
 André
 Anna
 Atom
@@ -19,11 +21,15 @@ BY
 BY-SA
 Binet
 Bitbucket
+BobAlice
 CDN
 CI
 CLI
+CRDT
+CRDTs
 Cantrill
 Clojure
+CoreData
 CouchDB
 DIY
 DVCS
@@ -31,6 +37,7 @@ Datomic
 EuAndreh
 F
 FFI
+FOSS
 FP
 FTS
 Fastmail
@@ -46,6 +53,7 @@ HN
 HTML
 HTTPS
 Halloway
+Hardenberg
 Haskell
 Henney
 Hodgson
@@ -57,6 +65,7 @@ JS
 JSON
 Joyent
 Kevlin
+Kleppmann
 L1
 LSM
 LTS
@@ -66,6 +75,7 @@ LilyPond
 LiquidHaskell
 Mailutils
 Matroska
+McGranaghan
 Mentat
 Merkle
 NPM
@@ -84,6 +94,7 @@ PoC
 PouchDB
 RDF
 README
+RPC
 RPN
 RSS
 Raku
@@ -108,11 +119,15 @@ UI
 URL
 VPN
 WebAssembly
+Wollrath
+Wyant
 Yandex
 YouTube
 Zig
 apk
+automerge
 bindgen
+blockchain
 boneco
 br
 brainer
@@ -136,9 +151,11 @@ euandre
 euandreh
 eval
 ffi
+fi
 fr
 frontend
 gcrypt
+ge
 gt
 guix
 guixbuild
@@ -178,6 +195,7 @@ org
 pastebin
 pastebins
 plaintext
+pouchdb
 progn
 pt
 rollout
@@ -192,6 +210,7 @@ só
 touchpad
 txt
 v8
+vlog
 www
 xp
 xyz