Sustainable Growth of Multilingual Open Publishing Projects: The Case of Programming Historian

Language for a Global Readership

Developing guidelines that support prospective and active authors to write for a global audience has been (and continues to be) a key mechanism towards achieving this alignment. Indeed, our current author guidelines (which are produced in each of the four languages we publish) include a section titled “Write for a Global Audience” which attempts to set out some principles to guide writing that is culturally inclusive and globally accessible.¹⁶ For instance, we caution against assuming that public figures well known in one’s own communities will be familiar to others; we advise avoiding vague or generalized references to geographical locations which inadvertently signal that everywhere else in the world is relative to a centralized, notional “here”; and we discourage jargon, jokes, syntactic puns, and other linguistic complexities.

Instead, we encourage authors to choose the clearest and simplest words possible to communicate their ideas—using the kinds of phrasing they might adopt if they were explaining their workflow to a colleague or peer, taking the initiative to define new concepts and preempt questions. Our readership is not only globally and culturally distributed but also broadly varied in their skill sets and learning needs. We’ve understood that our readers include researchers working in academic humanities and social sciences departments, librarians, archivists, and self-taught programmers honing their skills, as well as autodidacts with other specialist interests. We want language to let readers in—not erect a barrier—and that means encouraging writing which makes ideas accessible to all readers, whether they are reading in their first, second, or third language.

Multilingualism from the Proposal Phase

We do understand, however, that the length and detail of this documentation means it is not the most effective way to convey our principles to prospective authors. A recent call for new lesson proposals for our English-language journal provided an opportunity for us to review and refine our Lesson Proposal Form.¹⁷ We want to ensure that the proposals we receive succeed in centering methods that support multilingualism and multiculturalism. Programming Historian in English is the eldest of our four journals. Currently, it receives the greatest number of proposals overall and a markedly higher proportion of proposals for original lessons than translations each year.¹⁸ Having published their first two translations (both from Spanish) in 2023, the English team have articulated an ambition to increase editorial capacity for guiding translations through the pipeline in 2024. As a publisher, we recognize this is an excellent opportunity to diversify participation and foster cross-team knowledge exchange about translation workflows and best practices. The proposal phase is an ideal time to encourage the selection of case studies which can be exchanged or would be pertinent across global research contexts. We ask authors to consider sample datasets on the basis that they are Open Access and suitable for substitution, adaptation, or translation.

However, there is not always a multilingual choice of dataset available. The production, preservation, and publication of large-scale data is a privilege of national archives and libraries that have substantial resources to invest in its digitization, backed by government initiatives to disseminate it openly and encourage research (Zaagsma 2023). Many nations may not have the funds, the infrastructure, or the governmental support to do so. Recognizing this global disparity is key to understanding why, sometimes, it isn’t possible to identify an equivalent of the type of data required to demonstrate a method. In these cases, the pedagogical focus will need to be adapted. Keeping the original dataset in place, our translators will be encouraged to provide additional support to their readers so that they can navigate, transform, and interpret research data in a non-native language.

In other cases, our authors actively choose multilingual datasets from the onset, to demonstrate the global application of the method their lesson explores. For example, “Introduction to Jupyter Notebooks” (Dombrowski, Gniady, and Kloster 2019) centers a dataset of Italian fanfiction, and “OCR and Machine Translation” (Akhlaghi 2021) uses documents in Russian as its case study example. Elsewhere, our translators have opted to retain the original language dataset. For example, the English translation of “Sentiment Analysis with ‘Syuzhet’ Using R” retains the Spanish-language novel Miau by Benito Pérez Galdós (1888) as its case study, to introduce scholars working with non-English texts to the complexity of handling accented characters and to “the intellectual problems of applying English language algorithms to non-English texts” (Isasi 2023). Other lessons, such as “La reconnaissance automatique d’écriture à l’épreuve des langues peu dotées” (Vidal-Gorène 2023), have focused on the challenges of working with non-Latin alphabets.

This is also our opportunity to promote the choice of tools which are documented and workable in languages other than English. Some software tools offer multilingual options to experience their graphical user interface (GUI), which supports navigation of menus, options, and buttons in readers’ preferred languages. Sometimes, a multilingual GUI may be offered, but full documentation isn’t translated. An example of this is Voyant Tools, on which Programming Historian en español published an original lesson by Silvia Gutiérrez De la Torre in 2019, which has an optional Spanish interface but doesn’t offer Spanish documentation. Meanwhile, the Map Warper tool has neither a multilingual GUI nor documentation, and in this case the Spanish-speaking authors of a lesson on the tool opted to create animated visual aids to support user navigation of the interface (however, this solution raises its own barriers to accessibility unless detailed, descriptive alt text is also provided).

Each of our lessons is graded on a scale of 1 to 3 where 1 indicates beginner-appropriate, 2 defines intermediate, and 3 signals a high level of difficulty. We recognize that the need to negotiate technical documentation in a language other than one’s own increases a lesson’s difficulty level. So, where multilingual documentation is not available, we encourage authors to be explicit about this fact and to include multilingual references for further reading wherever possible. In particular, the Proposal Form foregrounds open tools, open source software, and open programming languages. We consider openness as an extension of our commitment to multilingualism, because choosing open recognizes the imbalance of computational and financial resources across our readership community.

Reviewing our Lesson Proposal Form prompted us to realize that, up until now, we had neglected to explicitly encourage authors to consider, at the earliest opportunity, how the lesson they would like to share with our readers could be translated and localized by other language communities in the future. In the revised form, we specifically ask prospective authors to think about multilingualism from the beginning.¹⁹ Prompting them to provide us with information about how their method or tool could be applied or adapted for use with non-English-language data, we state our strong preference for those that could be used in multilingual research contexts. Our aim is to encourage proposals that are devised and developed for a global audience, with future translatability and multilingual researchers in mind.

These recent adjustments will also empower our managing editors and their teams in their assessment of proposals. In cases of textual analysis methods, translation can be constrained from the outset. The feasibility of a lesson’s application beyond its original language and character-set can be key to our editors’ decision about whether or not to invite submission.

Learning across Languages

After submission and throughout the editorial workflow, there is further work to do to ensure that the lessons we develop are convenient for translation in the future. As well as text and data assets, our lessons comprise code and visuals. Code can take a relatively “straightforward” form of raw blocks of script, prepared for readers to copy-paste and use. But these blocks frequently contain directives or “comments” preceded by a ‘#’ which signals to the compiler not to process them as part of the executable code. These in-line comments will always need to be translated. In cases where the lesson necessitates the use of specific code libraries of which the function names and variables do not exist in translation, commentary will need to be extended to provide clarification.

Since 2023, we have increasingly encountered authors who wish to integrate ready-to-run computational notebooks with their lessons.²⁰ This trend presents a range of challenges for our publishing workflows: it requires us to manage notebooks among existing assets, render and serve them to our readers, and coordinate future maintenance to ensure their sustainability. Most pertinent here is the challenge notebooks pose for future translatability. We’ve drafted some guidelines for authors based on an understanding that notebook assets will form part of the package of files for translation. If commentary from lessons is substantially extended in notebooks, we foresee an unacceptable increased burden upon translators. Therefore, the guidelines include a stipulation that notebooks should consist of the code and minimal in-line comments only and an agreement that section headings and subheadings in the codebook must mirror those of the lesson to support translators’ (and also eventual readers’) navigation through the lesson.

Visuals within our lessons range from screenshots to hand-drawings, maps, graphs, and annotated diagrams. These, too, can raise challenges for us in translation. When there is no multilingual GUI option for a software or programming tool, screenshots will need to be adapted with annotated overlays or additional labeling. Meanwhile, plots and graphs usually feature axis labels which our translators can reproduce in-code as they work through the steps of the lesson, substituting any text input with their own translations. Recreating diagrams that include extended text (denoting processual models, for example) has proven to be more time consuming for translators, because the underlying diagram form must also be created anew. To reduce this burdensome part of the workflow, we have introduced a requirement for “mute” copies (that is, without any text) of underlying diagrams to be provided in addition to the text-populated version at the time of submission. This “mute” copy supplies a base which future translators can adapt to add their text.

Complexities of Growing a Multilingual Infrastructure

Programming Historian’s publishing workflows are now supported by the publishing manager and assistant, who collaborate with our four language teams to administer and produce all journals. Although our staff collectively speak only two of the journals’ four languages fluently (French and English), they also succeed in providing a high standard of support to the Spanish and Portuguese teams, including the technical processing of lesson materials, small-scale adjustments to text and code, and the coordination of copyediting services. Another crucial aspect of the workflow is typesetting the submissions ahead of publication: figures must be captioned; technical terms must be highlighted; direct translations must be given where necessary; citations must be formatted in our chosen style. This work, as well as the daily management of directories and folders within our GitHub repositories, is manageable in languages that our staff do not speak or write, because they can visually parse and type the letterforms, accents, and punctuation characters.³¹ Latin languages are familiar enough that it’s possible for them to use linguistic intuition to pick out key terms and understand the general structure of the lesson, especially with the help of online translation software.

The administration and delivery of our publishing services depends upon effective written communication. Most of our exchanges take place in GitHub Issues where it is critical to write clearly, using simple language. Where possible, and with the support of our four journal teams, we’ve introduced templated comments which are translated across four languages. This helps us to ensure that all contributors understand the instructions or advice given, and our publishing team are planning to expand our use of translated templates for comments through 2024.

Despite our distribution across continents and time zones, we also regularly engage in spoken exchanges. Inter-team dialogue about general topics depends upon an agreement to use our most common shared language (English), the second or third language of the majority of our project team. Our commitment to maintaining collaborative, democratic, and open discussions means accepting this “good enough” yet imperfect solution. Its adequacy is contingent upon the continued efforts of all participants to be clear speakers and patient listeners.

We strive to cultivate a collaborative and non-judgmental environment, in which native speakers of each language can support each other by translating or reviewing the accuracy of their colleagues’ work in a non-native language. Historically, our project team’s volunteers have taken upon themselves the extensive work of translating contributor guidelines, as well as the administrative and structural texts required for our website. While we have always recognized and valued the skillful labor involved in translation, in the past we were unable to compensate individuals for that work. Since establishing our Institutional Partnership Programme in 2020 and professionalizing our publishing team from 2021, we have built capacity to invest in people to undertake that translation work.

Although these frameworks and practices for effective multilingual communication hold up to the demands of our four language teams, we are acutely aware that substantial commitment will be required to meaningfully and fairly adapt them as the project grows. Integrating a language which uses non-Latin script, especially, would present a challenge of a different magnitude. The sustainable growth of the project in terms of adding new languages will likely require enlarging our professional publishing team, a goal only achievable through substantial growth in the number of Institutional Partnership Programmes or by designing new ways to achieve financial sustainability.

Devising a path towards growth also involves re-evaluating our current technical infrastructure. Our website was built in 2014 using Jekyll, an open and flexible static site generator which has enabled us to adhere to the principles of “minimal computing.”³² Notably, these principles make websites navigable and accessible by users with less powerful hardware or slower internet connections. Until recently, the Jekyll system has effectively accommodated our four journals and met the needs of our contributors, staff, and volunteers (Lincoln et al. 2022). However, future development of and support for Jekyll is soon to cease and its toolkit is gradually being deprecated. We are now experiencing excessively long build-times (up to 12 minutes) and encountering frequent and increasingly complex build errors that must be attended to before we can move our publishing pipeline forwards. Further scaling up our current architecture (to accommodate an additional language section, for example) would further increase build-times and slow the system as a whole.

To overcome this major issue, we are currently working on a technical infrastructure renewal project to address the limitations of our current system. Our expectation is to rebuild our website in alignment with our ethos, which means remaining committed to an open and minimal architecture. The goal is to create a website that can better meet the needs of our community through contemporary design that has low carbon intensity and adheres to accessibility best practices. To achieve this, we will need to partner with potential funders who share our vision for a robust and sustainable multilingual open publishing infrastructure for hosting our learning materials.

As things are, the inherent limitations of both our human and technical infrastructure therefore create a bottleneck in our trajectory towards growing Programming Historian multilingually. These limitations highlight the tension between ensuring the sustainability of a publishing project and the desire to serve a broader linguistic community. However, this issue also underscores how the power of an open license could help us to keep “the language door” open.

Harnessing the CC BY License to Empower Multilingual Growth

At its core, the Programming Historian project is a not-for-profit charity with a pedagogical mission: to teach and disseminate valuable digital humanities learning resources for free, to users around the world. As part of our commitment to open source values and practices, we publish all our journals under the CC BY 4.0 license. This choice affords us a powerful alternative for reconciling our aspiration for growth with the sustainability of our infrastructure. Perhaps a key to understanding the core principles and affordances of this license is to individually examine the constituent parts of its name, “Creative Commons Attribution.”

“Creative” tells readers that they are free to adapt the original work in any way: they may use it for a different purpose, recreate it in a different language or through a different medium. This term encourages a creative reuse of the work in its original form, to expand its reach to a wider, perhaps completely new, audience. “Commons” indicates that users are free to share the original work (or their adaptation) through their own channels, even commercially. Part of a commitment to openness is accepting to share the work among the community for free. Authors remain the copyright owners, but they understand that the work is now a “common good,” which belongs to all. “BY” represents the third pillar of the CC BY license: attribution. Indeed, the only restriction to the ultimate freedom given to users is that they must, whenever they either share or adapt the work, always attribute the original author and declare any modification.

A CC BY license therefore holds fast to the principle of credit where credit is due by demonstrating an effort to recognize the labor and the people involved in creating works of value, especially when they have been published Open Access, for free. Crediting the author means that they still have something to gain: in the academic world, recognition can essentially be capitalized upon through career advancement. Because of our awareness of the skill and effort involved in publishing and translating, Programming Historian is adamant about crediting all contributors to our lessons—not just the author. We are somewhat unusual in acknowledging the skilled labor volunteered by authors, translators, editors, and reviewers of all our lessons, a practice deeply tied to our celebration of multilingualism.

Within its terms, the CC BY license enables each of our four journals to translate, adapt, and localize what we have already published across their collective directories. Our broader impetus for choosing a license which offers the freedom of adaptation and circulation, however, is that it opens opportunities for others to do the same. Thus, our commitment to multilingualism is not solely limited to the language teams currently working under the Programming Historian umbrella: various non-affiliated groups and individuals have already taken up this opportunity to translate and localize some of our lessons for their own audience. As we saw above, the Spanish edition began with an ad hoc translation by the Mexican historian Victor Gayol. In 2020, Nobuhiko Kikuchi at the Kansai University Open Research Centre also translated and published six of our lessons from English into Japanese, showcased on the university-managed East Asia DH Portal.³³

These examples reinforce the strength of the CC BY license as a vector for multilingualism across languages and cultures. As a team who accept our own limitations, we recognize that we don’t have omniscient knowledge of the digital humanities landscapes and all its cultural nuances. The Japanese initiative allowed our resources to be distributed beyond the reach of our internal spheres of expertise. By sharing ownership of our lessons with others, we allow those better-placed to choose when, where, and how to adapt and distribute them, rather than attempting to encompass adaptations within our own infrastructure.

One of the ways we have already attempted to communicate the opportunity of the CC BY license more explicitly is to develop a formalized copyright declaration form. We recognized that our previous practice of asking authors and translators to grant their permission to publish—by way of posting a comment on the issue dedicated to their lesson—was inadequate. First, we noted that contributors were being prompted to grant this permission before the process of editing, review, and revision were complete; we felt strongly that the agreement should instead be arranged when lessons are shaped and ready for publication. Second, we sought a formal way to underscore that the license under which we publish allows, invites, and encourages creative reuse. Our objective was to distill and clarify the terms of the license so that authors and translators understand their own freedoms and the freedoms that will be afforded to others upon publication of their lesson as a common good.

We invested in the translation of the Authorial Copyright and Publishing Rights form into all four journals’ languages, appreciating the importance for contributors to be able to read the agreement in their preferred language before signing to confirm their understanding and grant their permission for us to be the first publisher. Within the formalized declaration, we include our own brief, context-specific summary of the license alongside links which direct to the Creative Commons organization’s own short, digestible summary of the deed as well as the full legal code. The deed and the legal code are available in a range of languages, including all four of those represented by our journals. Again, this is important because it enables contributors to read the text—which is technically and semantically complex—in their preferred language.

However, increasingly we recognize that we have perhaps done too little to explain and promote the affordances of our license. We have been approached by several groups who express a keen interest in adapting, translating, or creating Programming Historian lessons. Their requests are most often framed within a request for formal integration into the project, which indicates that we have not made the freedoms for creative reuse with attribution entirely clear.

We can understand why these external groups might prefer to join our publishing infrastructure rather than work independently to develop their own. We have the benefit of two paid, dedicated staff; we have developed structured workflows and policies over the years; we have an established readership; and our name is recognizable in the field. While we remain committed to extending participation and expanding global readership, our priority is to manage capacity so that existing editions are sustainable.

However, we are particularly keen to find alternative ways of encouraging, supporting, and nurturing initiatives that emerge from the opportunity offered by our CC BY license as self-organized “community teams.” We would consider this investment to be appropriately justified because these independent efforts have clear potential to empower an extension of our guiding objective, which is to advance education in the digital humanities through the production of lessons published in the public domain.

The support we might offer the community teams could take several forms. One is a program of direct training that centers upon sharing the accessibility and sustainability principles and best practice workflows we have developed. For example, by teaching others how we create and embed alt text to accompany images, collate authorial copyright declarations, or generate and apply archival links, we can help to increase the likelihood of their success. This will also pave the way to easily incorporate them into our infrastructure in the future.

Another idea would be to aid promotion of community-led initiatives through our website and social media channels. We could collaborate to devise a publicity campaign including blog articles, social posts, and announcements in our quarterly newsletter to support dissemination of the new resources created by external communities. We have built a substantial network of readers, contributors, and supporters and established a wide circle of connections across various social media. These networks and platforms afford us the advantage of a “voice” that can speak to many people and organizations beyond independent groups’ reach.

We’d also like to make these projects more “visible” on our website. At the moment, we simply include a citation and a link to independent initiatives within our Project Scholarship pages.³⁴ But community-led work could be given more prominence by dedicating a page of our own website to showcase independent groups’ outputs and direct readers towards the external sites where they have been established. This page could also provide space to explain what our CC BY license invites and what forms of further support we can offer, underscoring our commitment to encouraging multilingual growth through creative reuse beyond our current infrastructure.