LibreOffice Native Language Projects – TDF Annual Report 2025

TDF Annual Report 2025 banner

LibreOffice is available in over 120 languages, thanks to the work of localisation communities around the world. We asked them to summarise their work in 2025 – here’s what they had to say…

Czech

The Czech community maintained an active presence both online and in-person. Their localisation efforts remained strong, keeping the UI fully translated and the Help files at 95% completion. The team also stayed connected with their user base through the Czech Ask LibreOffice site along, with social media presence across X, Facebook, Instagram and Mastodon.

There was also outreach at events. The team hosted dedicated LibreOffice booths at InstallFest in April and LinuxDays in October, both held in Prague. Documentation also saw significant updates, with the publication of the Getting Started Guide (24.8), the Calc Guide (25.2), and the Draw Guide (25.8).

LibreOffice booth at LinuxDays 2025 in Prague

Danish

The Danish community focused on multimedia education and consistent localisation in 2025. There was the launch of the @libreofficeskolen (“LibreOffice School”) YouTube channel. This initiative provides the Danish-speaking public with a series of instructional videos designed to lower the barrier to entry for new users. Alongside this output, the community kept the UI and Help files fully translated at 100%, and ensured that LibreOffice promotional videos were accessible via localised subtitles.

Dutch

Beyond maintaining the local website and providing assistance via the Ask LibreOffice website and mailing lists, the Dutch-speaking community worked on many documentation updates.

Beginning in January with the Calc Guide for 24.8, the community then published a steady stream of translated manuals for version 25.2, including the Writer, Impress, Math, and Getting Started Guides. This effort then lead to the release of the updated 25.2 Calc Guide in July. On the localisation front, the Dutch team continued their work on Weblate, successfully maintaining 100% translation coverage for both the User Interface (UI) and the Help system, following upstream changes.

Finnish

The Finnish community focused on steady and ongoing translation efforts. The team prioritised localisation of the UI, with secondary work continuing on the Help system. To ensure the long-term sustainability of these efforts, the community has been proactive in outreach, utilising the vapaaehtoistyo.fi online platform to recruit new volunteers.

French

On the technical front, the French-speaking team maintained 100% translation coverage for both the UI and Help systems across all versions of LibreOffice. Their localisation work extended to the new Hugo-based website, release notes, and the Extensions wiki page. Significant progress was also made on the translation of Calc functions on the wiki and the subtitling of promotional videos.

Outreach was a major topic in 2025, with the community representing LibreOffice at events like Capitole du Libre in Toulouse, and Open Source Experience in Paris. The team also worked on academic ties, coordinating with UBO University to involve translation students in user guide writing. Beyond documentation and QA, the French team supported users through the Ask LibreOffice site and published various articles on LinuxFR. In addition, there were REGEX tutorials for civil servants and introductory presentations at public media libraries.

German

Throughout the year, the German-speaking community wrote blog posts (and translated others from the English-language blog), maintained its social media activity on Mastodon, and worked on user interface translations. Community members also attended local events on behalf of the LibreOffice project, such as the Augsburger Linux-Infotag 2025 and Digitaltag 2025 in Duisburg.

LibreOffice booth at the Augsburger Linux-Infotag 2025

Irish

The Irish-speaking community made significant steps in 2025 to bring the suite to native speakers. Currently, the UI and website translations are nearing 100%, with the LibreOffice 26.2 user interface already reaching a 96% completion rate. The team’s primary focus is now on finalising these remaining strings and resolving technical checks.

Italian

The Italian-speaking community maintained 100% translation status for the UI and Help files across all active versions of the suite. The team helped with localising the project’s new Hugo-based website and kept the Italian-speaking public informed by translating all release notes and press releases. Current efforts are focused on the ongoing translation of Calc functions on the wiki and a comprehensive revision of various wiki pages.

In 2025, the Associazione LibreItalia organised a full-day LibreItalia conference in Gradisca d’Isonzo, following the adoption of a regional law mandating the use of free open source software in Friuli Venezia Giulia, an eastern Italian region bordering Slovenia. The politician who signed the law provided an overview of the approval process.

The event was organised by Marco Marega, a long-standing member of LibreItalia who is active in the localisation team and other areas of the project. Several members of the Pordenone LUG attended the conference and initiated a discussion about organising the 2026 LibreOffice Conference in their city. This discussion then evolved into an official proposal.

Japanese

The Japanese community had a busy year in terms of events. There was the LibreOffice Asia Conference 2025 in Tokyo, a two-day event that brought together 70 attendees. Outreach extended internationally as Japanese members traveled to COSCUP 2025 in Taiwan to deliver three talks and strengthen ties with the Taiwanese community.

The community also organised:

  • Online Hackfests: Held 46 times via Jitsi and YouTube Live
  • Online Study Parties: Three sessions dedicated to user knowledge sharing
  • LibreOffice Days: Monthly offline meetups in Osaka, co-hosted with the Open Data Mokumoku-kai
  • Open Source Conferences (OSC): Booths and hackfests at seven locations across Japan, from Hokkaido to Fukuoka

On the documentation front, the team published the Writer Guide for LibreOffice 25.2 in Japanese. Localisation efforts currently stand at 91% for the UI and 46% for Help. The team also remained responsive to end users, answering nearly 50 new questions on Ask LibreOffice, publishing 20 blog articles, and maintaining a steady presence on X, Facebook and Bluesky.

LibreOffice Asia Conference 2025 logo

Kazakh

Starting in late 2025, the community launched a refresh of its translation efforts, achieving 100% UI completeness in time for the LibreOffice 26.2 release. This work extended to the localisation of the official website and the activation of the Help master branch, preparing for future documentation projects.

To improve consistency across other open source projects, the team is currently developing a unified Kazakh glossary derived from various localisation projects. Furthermore, the community has begun testing the use of AI-assisted translations, reporting high-quality results to improve their workflows in 2026.

Tagalog

The Tagalog community made steps forward in localisation, maintaining the user interface and Help files at a high completion rate of 98–99% across all versions. The team continued to integrate Deep Language Modeling to automate accuracy verification. While the community experiences a natural ebb and flow of contributors, there is growing interest in expanding support to regional dialects, such as Ilocano.

The team also wishes to extend a special note of gratitude to the dedicated group of US-based translation helpers whose contributions were vital to success in 2025.

TDF says: many thanks to all native-language projects for their work in 2025! Of course, this is just a selection of their activities, based on communities that reported their activities, but there are many more too.

Like what we do? Support the LibreOffice project and The Document Foundation – get involved and help our volunteers, or make a donation. Thank you!

How your donations help the LibreOffice project and community

LibreOffice is free thanks to your donations. Here’s how your support helps us to improve the software and grow the community that makes it 😊 (Note: this video is also available on PeerTube.)

Please confirm that you want to play a YouTube video. By accepting, you will be accessing content from YouTube, a service provided by an external third party.

YouTube privacy policy

If you accept this notice, your choice will be saved and the page will refresh.

There is no digital sovereignty without ODF

Any other choice is a choice of dependence on a single vendor

Digital sovereignty begins with the document format. Everything else – server location, hosting jurisdiction, procurement clauses – is downstream of this single decision. If the format is standard and open, the user controls the document. If the format is proprietary the vendor controls it, even when the file sits on the user’s own hard drive.

This is why LibreOffice, and its derivatives such as Collabora Office and Online, are today the only legitimate choice for governments, supranational bodies, businesses and organisations that want to protect the digital freedom of their users. Only software based on the LibreOffice source code – the LibreOffice Technology – uses ODF as its native document format. Every document saved, stored, retained and exchanged in ODF remains the exclusive property of its author, and remains so over the years.

ODF – Open Document Format, as the name says – was designed and developed in accordance with the characteristics of a true open standard: clearly documented, transparently developed by an independent body, properly versioned, built on existing standards, and stored in XML files that any user can read.

None of this applies to OOXML. The name is itself an oxymoron: XML stands for eXtended Markup Language, which is open by definition, but OOXML’s syntax is so complex that it is unreadable even to advanced users. The format was deliberately designed to become a sophisticated lock-in tool at a moment when Microsoft’s other strategies had already been uncovered and analysed.

The Transitional/Strict bait-and-switch

OOXML was approved as an ISO standard through a process that was an affront to transparency, ethics, common sense and respect for users. The format is documented in a way that discourages consultation – over 7,500 pages – and is developed by Microsoft behind closed doors in Redmond.

It is not versioned. It uses no independent standards. On the contrary, it relies on proprietary Microsoft formats wherever possible, in some cases formats that Microsoft itself had deprecated because the market rejected them. It is not even compatible with the Gregorian calendar. The XML schemas are nearly absurd in their complexity.

The bait-and-switch worked like this: “I swear it will be Transitional until 2010, very proprietary and very little of a standard, and after that only Strict, not very proprietary and very much a standard.”

The catch: Strict never materialised in practice. For years it lingered as a last-resort option that no one was meant to use, and it has now disappeared from the Save As options altogether. The standardised version of OOXML – the one ISO was told would become the real format – no longer exists as a user choice. Only Transitional remains.

A pity, because we would have had a laugh with Strict’s bugs. Excel has a thing for getting dates wrong (the (in)famous 1900 leap-year bug, inherited from Lotus 1-2-3 and never fixed), and when Excel gets dates wrong, no other software does it worse.

The political consequences

All of this is hard to grasp by looking at what happens on screen, because the document seems entirely harmless in its apparent simplicity. And yet all of it has been documented in detail since OOXML was first introduced, by independent experts who should have been heard, both by ISO and by those working in advanced technology.

Instead, ISO bought the Transitional/Strict story. And once ISO believed it, governments and politicians believed it too, rushing to adopt OOXML as a document format for fear that Bill Gates and Steve Ballmer might take offence and act accordingly.

In doing so, they placed citizens’ private data in Microsoft’s hands and reinforced a monopoly that was already evident before OOXML’s arrival, and that has become increasingly difficult to dismantle ever since.

The Microsoft ecosystem played its part in all this, and partner companies – SAP foremost among them – have always done everything in their power to push their users toward OOXML for data exchange, openly obstructing the use of the standard ODF format. An uneven struggle, by design.

Worse still, with just a few exceptions, even those who by virtue of their expertise should have recognised OOXML as the cornerstone of Microsoft’s new lock-in strategy fell for it. Some still write today: “we have to accept it, OOXML is an ISO standard.” This is not a serious position.

It is a deference with no rational basis.

Microsoft’s monopoly position is not founded on technological superiority but on the strategic foresight of Bill Gates and the lobbying machinery that flowed from it, deployed well ahead of its time.

The same deference has had consequences in the scientific community as well.

The HUGO Gene Nomenclature Committee was forced in 2020 to rename dozens of human genes – including SEPT1 and MARCH1 – because Excel kept silently converting their symbols to dates. Rather than going to Microsoft and demanding a bug fix, scientists preferred to throw years of established nomenclature down the drain to avoid upsetting Redmond. A revealing precedent.

Supporting ODF is not choosing ODF

There is a distinction that needs to be made plainly, because it is too often blurred, sometimes inadvertently, sometimes by design. Supporting a format is not the same as choosing it.

An office suite that saves OOXML by default is not supporting digital sovereignty, independently from the level of ODF support. It is an OOXML suite with an ODF import/export filter, which inherits all the OOXML based lock-in mechanisms: proprietary schemas, vendor-controlled evolution, hidden binary fragments, format-level dependencies on Microsoft’s roadmap.

Digital sovereignty lives at the native-format layer. Support describes what a piece of software can read. Native format describes what it is. The native format determines the legal and technical character of every document the user creates.

A commitment to “improve ODF support” is not a commitment to digital sovereignty. It is a commitment to keep ODF as a guest in someone else’s house.
This distinction matters for any project, coalition, or procurement decision that claims a digital sovereignty objective. The meaningful question is never whether ODF is supported – it almost always is, at some level – but whether ODF is the native format, chosen and committed to as such.

If the answer is anything other than yes, the sovereignty claim is provisional at best.

What digital sovereignty actually requires

The only viable path to digital sovereignty today is to use ODF as the native document format, and OOXML as the interoperability format for exchange with users who – out of lack of information, or pure convenience – continue to use the proprietary format, and share ownership of their own files with the vendor.

Anything else is false digital sovereignty. Control over a document and over the information it contains depends first on the format and only afterwards on the location of the server.

Standard, open format: the user is in control. Proprietary format: the vendor is in control, even if the document sits on a PC on the user’s desk.

This should be self-evident to anyone working in open source software, because it follows directly from its principles.

A proprietary document respects neither Freedom 1 (the freedom to study and modify) nor Freedom 3 (the freedom to improve and redistribute), as it is not not documented in a way which makes the source code readable and it is not developed through a transparent process.

The decision to adopt OOXML as the native format runs counter to the interests of governments, supranational bodies, organisations of every kind and enterprises. But above all, it runs counter to the interests of users as it exploits their lack of information rather than investing in their education and in their digital sovereignty.

The choice of native format is not a technical detail to be deferred or finessed. It is the choice. Any project that treats it as something less is not supporting digital sovereignty. Full stop.

Why a digital document is a piece of software, and what that means for your freedom

Most people, including many competent software developers, think of a digital document the way they think of a sheet of paper: an inert object that holds words and pictures, indifferent to the tool used to open it. This intuition is wrong, and the consequences of getting it wrong shape everything from vendor lock-in to cybersecurity to the long-term readability of public records.

A digital document is not paper. It is a piece of software.

The HTML parallel

The clearest way to see this is to think about a web page. When you visit a website, your browser receives a file – an HTML document – and executes it. It parses the markup, applies styling rules, runs embedded scripts, fetches additional resources, and assembles the result into something you can read. The page you see on screen is not a static image transmitted from the server, it is the output of a small program that your browser ran on your behalf.

Nobody disputes that a web browser is software. Yet the HTML file it consumes is also, in a meaningful sense, software: a set of instructions describing what should happen when the file is opened. Change the instructions, and the rendered page changes. Withhold the specification of how the instructions should be interpreted, and only the party holding the specification can guarantee a faithful rendering.

It is worth remembering that the openness of HTML did not happen by accident, and was nearly lost. In the early 2000s, Internet Explorer 6 commanded around ninety per cent of the browser market, and Microsoft used that dominance to push proprietary extensions to HTML, CSS, and the document model: non-standard tags, behaviours, and filters that worked only in their browser.

Web developers, desperate to reach users, began coding both to Internet Explorer and to the standard, carrying the cost of that double work themselves, while the vendor reaped the benefit of lock-in either way. The open web did not fragment, but only because developers absorbed the cost of holding it together. Had they stopped, HTML would have quietly become whatever Microsoft shipped next.

It took a sustained effort by the W3C, by competing browsers such as Firefox, and by the community of standards-conscious developers to pull the web back onto open ground. Had that effort failed, HTML today would not be a shared language, but a Microsoft product. The web survived because the standard was defended. Document formats have not always been so lucky.

An office document – a DOCX, an ODT, a PPTX, a PDF – works exactly the same way. It is a structured file containing instructions: this text in this font at this size, this image embedded here, this table laid out this way, this field recalculated automatically, this macro executed on opening. When you “open” the document, an application reads those instructions and runs them. The page you see on screen is the output of a program – the office suite – executing the instructions contained in the document.

The document is the code. The office suite is the interpreter. Together they are a software system, and the user is the one running it, usually without realising.

Why this matters: lock-in is a software property

Once you see a document as software, the question of file formats becomes the question of programming languages. A proprietary file format is a programming language whose specification is owned, controlled, and modifiable at will by a single vendor. The “programs” written in that language – your contracts, your invoices, your books, your public administration archives – can only be reliably executed by software that vendor authorises.

This is the structural mechanism of lock-in. It is not a side effect of user habit or training cost. It is the direct consequence of writing your documents in a language whose grammar belongs to someone else. The moment the vendor changes the grammar – and proprietary formats change constantly, at least with each new product release, but often even more frequently – your existing documents may render differently, lose features, or stop opening altogether. You do not own the language in which your own records are written.

Open standards such as ODF exist precisely to break this dependency. ODF is a publicly specified, independently maintained format whose grammar belongs to no single vendor. Any developer can build a faithful interpreter. Your documents, written in an open language, remain readable regardless of what any single company decides.

Why this matters: attack surface is a software property

The second consequence is security. Software has vulnerabilities, paper does not. The moment we admit that a document is software, the long catalogue of OOXML-related security advisories becomes unsurprising, and inevitable, indeed.

Office document formats are ferociously complex. OOXML in particular runs to thousands of pages of specification, with macro languages, embedded OLE objects, external references, conditional formatting logic, and a substantial layer of binary legacy compatibility. Each of these is a way in for an attacker. A document that arrives by email and “just opens” can run hidden code, download malicious content from the internet, exploit weaknesses in how the file is read, and from there take control of the computer itself. The pattern recurs year after year, vulnerability after vulnerability, because the document is doing what software does: running.

A simpler, more rigorously specified format is harder to weaponise. This is not a guarantee – any sufficiently expressive format has risks – but the principle holds: complexity is the friend of the attacker, and proprietary complexity, never fully documented to outside parties, is the best friend of all.

Why this matters: freedom is a software property

If a digital document is software, then the framework we apply to software ethics applies to documents. The Free Software Foundation defines four freedoms: the freedom to use the program for any purpose, to study and modify it, to redistribute copies, and to distribute modified versions. The second and the fourth – Freedom 1 and Freedom 3 – require access to the source.

A document in a proprietary format violates these freedoms in exactly the way proprietary software does. You cannot fully study how it will be interpreted, because the specification of the format is either secret, partial, or subject to unilateral change. You cannot reliably build or share modified tools to interpret it, because the format’s owner retains the right to declare your interpreter non-conformant. The “source code” of the document – the full and stable specification of what its instructions mean – is not in your hands.

This is not a metaphor. It is the same dependency, structurally, that makes proprietary software unacceptable for any organisation serious about digital sovereignty. The document, as software, inherits the politics of the format it is written in.

The conclusion is unavoidable

A digital document is a small program. It runs every time it is opened. The language it is written in determines who controls it, who can attack it, and whether its readers are free.

Treating documents as paper has allowed a generation of policymakers, public administrators, and even technologists to overlook the fact that the choice of document format is a choice of software dependency, and a choice of whose grammar governs our written record. There is no neutral format, just as there is no neutral programming language. There are only formats whose specifications are open, stable, and collectively governed, and formats that are not.

We have learned, slowly and at cost, to demand openness in our software. The document is software. The demand is the same.

The Document Foundation announces LibreOffice 25.8.7

Berlin, 12 May 2026 – The Document Foundation announces the release of LibreOffice 25.8.7, the final maintenance release of the LibreOffice 25.8 family, available for download at www.libreoffice.org/download [1]. Users of LibreOffice 25.8.x should update to LibreOffice 26.2.x as LibreOffice 25.8’s end of life will be on June 12, and after that date the software will not receive additional security updates.

LibreOffice 25.8.7 is based on LibreOffice Technology, which enables the development of desktop, mobile and cloud versions – either from TDF or from the ecosystem – that fully supports the two document format standards: the open ODF or Open Document Format (ODT, ODS and ODP), and the closed and proprietary Microsoft OOXML (DOCX, XLSX and PPTX).

Products based on LibreOffice Technology are available for all major desktop operating systems (Windows, macOS, Linux and ChromeOS), mobile platforms (Android and iOS) and the cloud.

For enterprise-class deployments, TDF recommends a LibreOffice Enterprise optimized version, with dedicated value-added features and other benefits such as SLAs and security patch backports for three to five years. Additional details at: www.libreoffice.org/download/libreoffice-in-business/.

English manuals for the LibreOffice 25.8 family are available for download at books.libreoffice.org/en/. End users can get first-level technical support from volunteers on the user mailing lists and the Ask LibreOffice website: ask.libreoffice.org.

LibreOffice users, free software advocates and community members can support The Document Foundation and the LibreOffice project by making a donation: www.libreoffice.org/donate.

[1] Fixes in RC1: wiki.documentfoundation.org/Releases/25.8.7/RC1. Fixes in RC2: wiki.documentfoundation.org/Releases/25.8.7/RC2. Fixes in RC3: wiki.documentfoundation.org/Releases/25.8.7/RC3.

Twenty Years On, ODF Is Still the Only Open Standard for Office Documents, and the Only One Governments Can Trust

Berlin, 8 May 2026 – Twenty years ago this week, on 3 May 2006, the Open Document Format cleared its Draft International Standard ballot at ISO/IEC JTC 1/SC 34 with unanimous approval. On 30 November 2006 it was published as ISO/IEC 26300. Two decades later, ODF remains what it was on the day of its ratification: the only open, vendor-neutral, freely implementable international standard for office documents in existence.

Everything else on the market is a vendor format with a standards number attached.

That distinction was contested in 2006. It is not contestable in 2026. The competing format pushed through ISO in 2008 – under a fast-track process whose abuses are now part of the documentary record of standards governance – has since splintered into a Strict variant almost no implementation actually uses and a Transitional variant that preserves, by design, the undocumented behaviours of a single vendor’s legacy products. A standard that exists to encode one company’s bugs is not a standard. It is a moat with a certificate.

ODF has no Transitional mode. It has no undocumented behaviours. It has no vendor whose commercial roadmap can quietly rewrite what conformance means. The specification is publicly available at no cost from ISO and from OASIS. The schemas are auditable. The implementations are multiple, independent, and free. This is not advocacy language. It is the working definition of a standard, and ODF is the only office-document format that meets it.

The political weather has finally caught up with the technical reality. Germany’s federal administration has mandated ODF through the Deutschland-Stack. The European Commission’s own services are under sustained pressure – including from this Foundation – to align procurement with the open-standards commitments the Commission itself has signed. Brazil has legislated open formats into its educational system through Lei 15.211/2025. The pattern is the same on every continent where public bodies have stopped to ask the only question that matters: in what format does a society keep its own records, and who decides when that format changes?

For twenty years, the answer to the second question – for any administration that chose ODF – has been: we do. For any administration that chose the alternative, the answer has been: the vendor does, and the administration will be informed.

“ODF is the document format of a public that has decided not to outsource its memory,” said Florian Effenberger, Executive Director of The Document Foundation. “The governments now mandating ODF are not making a technical choice. They are reclaiming a sovereignty they should never have surrendered.”

The implementation landscape reflects the same divide. LibreOffice, developed by The Document Foundation and a global community of contributors, uses ODF as its native format and is the reference implementation of the standard. Collabora Online extends ODF support to enterprise and cloud deployments. Together they constitute the working core of the ODF ecosystem. Other office suites – including those that market themselves with the vocabulary of openness while defaulting to a competitor’s vendor format – are not part of that ecosystem and should not be confused with it.

The Document Foundation will mark the twentieth anniversary across 2026 with a programme of publications, policy briefs, and community events. The LibreOffice Conference will dedicate a full track to ODF, coordinated with the OASIS Technical Committee, which is currently advancing version 1.4 of the specification. Material on the history, the structural design, and the policy implications of ODF will be published throughout the year on the TDF blog.

A standard is worth what it still does after the people who wrote it have moved on. ODF is read, written, and trusted by software none of its original authors imagined, on hardware none of them could have specified, in jurisdictions none of them lobbied. It has aged the way public infrastructure is supposed to age: quietly, reliably, and in everyone’s hands.

That is the anniversary worth marking. Not the certificate from 2006, but the twenty years of evidence since: evidence that the open-standards bet was the right one, that the alternative was the trap its critics warned it would be, and that the governments now choosing ODF are not innovating. They are catching up.