This is a property of type Text.
Pages using the property "Has summary"
Showing 18 pages using this property.
|Aisle/Features/Arabic Script +||Arabic script is RTL, and is heavy on ligatures. +|
|Aisle/Features/Collaborative Editing +||Think Etherpad. Collaborative Editing allows multiple contributors to edit the same file at the same time, seeing the mutual edits live. +|
|Aisle/Features/Language packs +||Language packs are great ways to create testable deliverables, with minor install hurdles. +|
|Aisle/Features/Latin Script +||Editing Latin script shouldn't be a challenge, but what would we do without it. +|
|Aisle/Features/Spellchecking +||Spellcheckers should run over the localized string values. +|
|Aisle/Features/Syntax Highlighting +||Being a source-based editor, syntax highlighting is crucial for the ease of use of Aisle. The emphasis should be on "localizable content", and there should be strong indications of format errors. There should *not* be auto-correction of potential errors. We'll want a comprehensive support of existing formats, and extensibility for future formats. +|
|Aisle/Goals/Consistency +||Consistency means that words and concepts of projects are using the same words in the target language. +|
|Aisle/Goals/Context +||Different words have different translations, depending on context. +|
|Aisle/Goals/Correctness +||The correctness of a translation is per entity linguistic correctness. +|
|Aisle/Paradigms/Attribution +||The biggest value that FLOSS projects can give back to their contributors is Attribution. Just tell the world who did what. In particular with the rise of distributed version control systems, having attribution as part of the version control history is key. Also, MPL 2 builds on that, and removed attribution from the license header. Thus, a good l10n tool for an open source project should create open source l10n code, with changesets that give attribution to the contributors, no matter where they originally made their contribution. It should be noted that DVCSes only know about Authors, and possible Committers. Roles like Reviewer or Proofreader are probably best stored in the commit messages. +|
|Aisle/Paradigms/Collaboration +||Collaboration is the actual real-time working-together of multiple contributors on the same work item. Collaboration is needed when the focus is on negotation or learning, when finding term bases or glossaries, or when doing sprints, or when onramping new contributors. When splitting up work to be done by contributors in parallel, but independently, we'd talk about Cooperation. +|
|Aisle/Paradigms/Cooperation +||Cooperation allows different contributors to work on different pieces of a project. Say, one volunteer works on Firefox, one on Thunderbird, and a third does QA work. Cooperation is the common pattern to work together in open source projects, real-time collaboration on the other hand is often harder to achieve. +|
|Aisle/Paradigms/Discoverability +||One of the biggest hurdle in taking contributions to an open source project is finding them. If you have a central install of a tool, say, github, or a particular narro install, owners can use the features there. But in a truly distributed fashion, it's a tough challenge to discover possible contributions, and mentor new contributors to team members or leads. +|
|Aisle/Paradigms/Federation +||Federation is important if you're in a global and distributed ecosystem. There are many reasons why you'd want to use a different tool, or why you'd like an online tool hosted independently. Being able to exchange work between multiple tools and their installs is important. +|
|Aisle/Paradigms/Interoperability +||Interoperability means that using one tool doesn't lock you in to that tool, let alone a particular installation of that tool. +|
|Aisle/Requirements/Performance +||Perceived performance in a localization tool is to be kept in mind on features. +|
|Aisle/Use Cases/New contributor +||New contributors need a bit of help to get by, and should see reward for their work quickly. Low barrier of entry matter as well as opportunities for experienced contributors or mentors to guide. This has Grow Mozilla impact, of course. +|
|Aisle/Use Cases/Sprint +||Sprints are a powerful tool to make significant progress in a localization project, enjoying the high bandwidth communication of a group of people being together focused on one task. Usually sprints are held in real-life, though virtual sprints are also happening. You'd want an experienced contributor to guide the sprint, and pair that with possiby quite new contributors. +|