Peter Eisentraut

PostgreSQL has supported national language support (NLS) (that is, message translations) with Gettext for over twenty years. This has been a valuable feature, but naturally not without challenges.

I have been involved in this effort as a toolsmith, organizer, and translator.

We have had interesting challenges making Gettext work reliably in a client/server system and to make it cooperate with the other internationalization facilities in the system. We also had to write a lot of our own tooling to manage the translation work, merges with the code, and so on. We also have translations of the documentation, which use separate workflows. PostgreSQL is a relatively small community and the software is mostly not facing end users, so the possibilities for recruiting translators and other volunteers for this are limited.

In this presentation, I want to give an account of the work we have done in the PostgreSQL project to make translation and internationalization in general an integral part of the project and start a conversation with other practitioners about best practices and the future of the tooling.

PostgreSQL has been maintaining its documentation in DocBook for over twenty years. It's been successful but not without challenges. PostgreSQL is often praised for its excellent documentation, and PostgreSQL is also often criticized for its hard-to-approach documentation.

Maintaining documentation for a project such as PostgreSQL comes with a number of challenges. There are many challenges writing good documentation, but in this talk we'll focus on the tooling. First, the documentation is quite big: In a printable format it is over 2000 pages. This pushes many build tools beyond their limits. And of course we also want documentation builds to finish in a reasonable time. Second, we need tooling longevity and portability. Database server software is long-running software. We still need to be able to patch and rebuild everything many years from now. In the world of writing and publishing tools, there is often a new idea every few years with many dependencies and no long-term track record, which makes it difficult for us to adopt things like that. It took us many years to get just a few graphics into the documentation because the tooling issues were too overwhelming.

DocBook has been good to us, but there have been plenty of struggles along the way, and there are some concerns about the future.

I did the Advent of Code 2020 with a different programming language every day, so instead of having to visit 25 developer rooms, you can just listen to me for my lightning summary.

Over many years of PostgreSQL development I have collected a lot of information about setting up a development environment and assorted notes about the development process that would be worth sharing. If you are new to PostgreSQL development, this can help you get set up. If you are an experienced developer, we can compare notes.

Topics covered include:

• git setup
• shell setup
• editor setup
• tags
• documentation
• using configure and make well
• core files, backtraces
• running tests
• test coverage analysis
• profiling
• sending patches
• reviewing patches
• dealing with odd platforms
• dealing with multiple branches