Official Languages - Langues officielles

[gcharest]

trafficstars

Feedback has highlighted that requiring projects to be fully bilingual (from source code comments, to configuration documentation, user interface, API references, training material, etc.) could discourage the community in open sourcing their projects. Maintaining project documentation up-to-date is already a challenge for development teams in general, having to maintain bilingual versions of everything related to a project may create further resistance and lead to no projects being outsourced or .

As such, we need to find the right balance in being compliant with the Official Languages policies and enable the projects team in thriving with their development.

To be confirmed/clarified:

• What should and shouldn't be bilingual in an open source project?

To note: I believe that having a project with localization incorporated in its development when applicable should be seen as an advantage to build a large multi-cultural and inclusive user base and community. That being said, source code and comments found within shouldn't be subject to Official Languages. The rest of a project should abide to the same principles any other information technology project, including proprietary solutions, has to be subject to, including end-user documentation in official languages.

From my personal experience, anything that is to be used by a non-technical end-user should be bilingual: Graphical User Interface (exclude command-line), End-user documentation.

Looking forward developers, user experience designers, users, official language advisors and others' input.

[gcharest]

So, I've been going over other Standard and although there are mentions and references to Official Languages Act and policies, they do not directly reflected them in the requirements sections (except for one about Web site and mobile apps).

I will be taking the similar approach for now and will keep the discussion going here.

[uferrpi]

I agree with you Guillaume for several reasons:

• while code should be in English, user and admin interfaces should be in both official languages. As stated previously, building a digital nation requires strong gestures : make all government Open Source work in the languages of both founding nations.

• making solutions in both languages is not a hassle, just a question of organization. The EU does it in 10+ languages! Us in Québec could help both on translation and Open Standards linked to development and procurement relating to languages. A few years ago we translated 5 000 + terms in BuddyPress... in three days.

• procurement wise (i.e. subcontracting development), it has never been a problem for us to make it mandatory, except once, from an Ontario contractor.

[gcharest]

@uferrpi merci pour ces ajouts! Je pense que c'est en effet un avantage au même titre que d'inclure la sécurité et l'accessibilité par défaut.

En définissant adéquatement nos balises, il est possible de développer des solutions réutilisables par d'autres organisations. Et cela ouvre ensuite la porte à des collaborations par une plus grande base de contributeurs.

[wardi]

Some things that should never be covered by OL:

• API endpoints (API reference may be in both languages)
• keys in API messages (API examples may be in both languages)
• parameter names (documentation in both languages)
• CSV data column headings (data dictionaries in both languages)
• identifiers ("codes") for controlled lists (descriptions in both languages)

Separately, there's the pattern of having separate English and French domain names. Can we do bilingual domains instead? Being logged out suddenly when switching languages is pretty annoying. Or If there's another way to manage shared logins across different domains please let me know!

[matthewdarwin]

Hopefully when all logins are controlled by myaccount.canada.ca (or whatever the single sign-on is called), then dual domain names is not a problem. I'm waiting for the day when someone adds accents to the domain names.... https://météo.gc.ca/ why doesn't that work? https://meteo.gc.ca/ works.

[pjackson28]

@wardi According to the Canada.ca Content & IA Spec (required by Directive on the Management on Communications), the following is stated: "For digital services that use a session to manage parameters, when the language of the page changes the sub-domain can remain in the same language as when the session first started". That should prevent the logging out when switching languages (source: https://www.canada.ca/en/treasury-board-secretariat/services/government-communications/canada-content-information-architecture-specification/conceptual-overview-user-navigation-key-templates.html#toc3)

[pjackson28]

@matthewdarwin Probably related to the overall URL support being focused on 7-bit US-ASCII. characters. So support for unencoded special characters in URLS is likely not that reliable. Even France sticks to 7-bit US-ASCII characters for it's Government website (e.g., https://www.gouvernement.fr/donnees-personnelles-et-cookies)

[matthewdarwin]

Of course you should both with and without accents. We're in 2018.... UTF-8 is standard and it should work everywhere.

[wardi]

@pjackson28 thank you that's very helpful!

[keithdouglas]

In hostnames one can use so-called PunyCode.