2 posts were split to a new topic: Which pad hosting platform should we use?
Hello everyone! Sorry for the delay in sharing notes and updates (pardon, but still in the contested Sandstorm pad for the time being) from our discussion last Thursday.
A concise summary of the 04/19 meeting:
We primarily looked over the Mozilla Style Guides (also published with GitBook) and discussed how these existing language team style guides could be utilized and adapted to support Localization Lab supported projects as well as further development for the Mozilla teams.
Language Team Style Guides:
One proposal is to fork the Mozilla style guide and contribute to it instead of reinventing the wheel. If / when is not relevant to both the LocLab and / or Mozilla teams or consensus cannot be reached between both organizations’ contributors, developments can be made to the LocLab fork.
General Project Style Guides:
We briefly discussed how to deal with project specific guides. @dachary recommended that there be a general LocLab style guide that individual projects then fork and develop as opposed to LocLab maintaining project-specific content in the guide. Maintaining all projects in one repository will likely be messy as projects come and go. For projects that do not have the technical skills or resources to fork and maintain their own guide, it can be done by LocLab.
@dachary met with me today to propose a trial-and-error approach for developing style guides from last week.
The approach starts small, focusing on one language team to test the process, document it, and then determine if it makes sense to scale or not.
Style Guide Trial Proposal:
- Create a Localization Lab framagit account and Style Guide project.
*Why framagit? Because it is free software, maintained by a non-profit, offers hosting and self-hosting options.
- Import Mozilla Style Guide
- Propose a modification to the style guide to illustrate how it is done.
- Make a sample publication of the style guide with modification.
- Select a guinea pig language team.
- Language team discusses a change they would like to make to the Mozilla language team style guide. (Preferably one that is likely to be accepted by Mozilla.)
- Propose change to Mozilla style guide.
- Discuss change with Mozilla team (which will then either be accepted or rejected.)
- Make any rejected changes to LocLab fork.
After following through with the above process and documenting, we can revisit whether or not this is a reasonable approach (and hash out publication details, soliciting language team contributions etc.) or if we want to go in a different direction.
Any takers to be the language team guinea pig?
@kwadronaut, I think there are several Dutch contributors potentially interested in the issue of consistency and quality control in Dutch technical translation. I spoke briefly with pljmn (very active on TX) about this awhile ago and they may be interested in contributing to this effort or if not, in providing constructive feedback on the approach. SilverXp may also be up for participating.
“Do note that this guide itself is just a partial copy of the one on mozilla-nl.org, both are heavily outdated, and not worth much these days IMO. Plans to revise them have been there for a while, but with low priority.”
The Dutch style guide also misses a handful of things, those will be taken for granted by most (units for example). So all in all, I’d expect to update the wordlist(s), rip out or rewrite the general guide related to branding… Best would be to setup a meeting with pljmn, SilverXp and whomever else is interested. Things like gender neutrality aren´t present in the current guides, so figuring out what´s missing and relevant would also be on the to-do list.
In your opinion, would the guide still serve as a useful base for development? Or would it be just as much work, or less to start from scratch?
Also adding that @drashti4 has been contributing to the experiment in framagit. I’m still dealing with a learning curve here, so welcome the perspectives of individuals with more familiarity with Git.
It definitely still has a lot of value. It´s also not too big, while rewriting from scratch will probably leave holes that should be addressed. This community has it´s own jargon that´s (partly) missing from the existing wordlists, some of which can flow back upstream. I can imagine that every language team can/should have a look at what Mozilla has done and what they need. Dutch´ needs (changes) are minimal. It can be a tiresome process to learn about the different existing communities (KDE, Gnome, Wordpress…), but it’s very worthwhile to interact and pick what you can learn from them.
@drashti4 and I chatted and thought maybe an effective way forward is to meet and test out the process of contributing to the guide together, providing feedback and asking questions in the process. If individuals are interested, I’m open to meet this Friday the 8th or the following Friday the 15th with the possibility of using the open LocLab community meeting hour for discussion.
Is there a URL to learn about this meeting? It looks like I missed it and it sounds interesting