Keeping it localized

    We thought of implementing a small web app in Go for localization of resources and translations. There are such apps available:

http://www.businessofapps.com/top-app-localization-tools/

    But then we thought it is not that important tool. The job can be accomplished in a shared spreadsheet. Like our example of issue tracking:

http://techzealous.blogspot.bg/2016/06/task-tracking-with-shared-spreadsheets.html

    The same can be done when we want to localize our resources or translate a text in multiple languages. One spreadsheet per language and we are done. No need for special tools, when everyone already is familiar and used to using the tool, in this case a spreadsheet editing program.

Automation, Not ?

    We all know that automation is good. No one likes boring repetitive task that can be passed to a machine to execute. But if we specifically and regularly are forced to change our code just to accommodate automation, well then "you are doing it wrong". Yes there are decisions that we need to make so that automation is possible, but it is possible through clean, well structured and maintainable code. That is it. (here is an article with the same opinion and some more things: http://ithare.com/testing-my-personal-take-on-testing-including-unit-testing-and-atddbdd/).
Automation should bend backwards, sideways and any other way to fit our workflow, not the other way around. Otherwise we are in the case of those memes, which mock "doing automation the manual way".