Sophie wrote: >> What we do not want in localised version is content in en_US language. >> Even if the sound is translated, UI still will be in English and it's >> very difficult to focus on what you learn when all what you see is in >> a foreign language.
In terms of the content that we provide on a per-language basis, I agree that it's important to be able to provide consistency to those users who desire it. For those who wish to see only content in language XYZ, then we should strive to show them only content in XYZ. On Wed, Dec 9, 2015 at 4:31 PM, Joel Madero <jmadero....@gmail.com> wrote: > Just for full transparency here. Sophie and I had an extended talk on > chat and I'm of the belief that to prevent this from getting into help > files because other locales aren't doing the same is not the smartest > way to move forward. I instead would prefer including it and then > supporting locales to do the same - in the respective languages, with > the right GUI, etc....These then would be linked in the locales help > files and it would empower the community, expand on the product, and > give visibility to a great tool (videos that literally show exactly how > to use features). For those who are multilingual or just adventurous, I can see the potential benefit if users could choose on a program-wide level to toggle on extra non-localized content (let's call it "Extended Documentation") for each page of the Help. If we were to have rather stringent rules about what content (format, length, structure, license, etc..) could be included in this fashion, then we'd have a decent roadmap on what content we'd like to see localized next. If we're clever about how we include Extended Documentation, we could even recruit for translation/localization by adding a small message to any non-localized content such as "Want to see this content in $CURRENT_LOCALE? Click here to help out!" > I'd prefer discussing a better solution, one where we can agree that the > tool is awesome for users, that the more visibility the better, and one > that empowers contributors to follow Robert's lead and developer > tutorial videos in their respective languages. I'd suggest that any video content included or linked from the Documentation be provided in a similar fashion to our existing text content. Off the top of my head, this would include: - Licensing under CC-BY or CC-BY-SA 3+ - Use of free/open file formats - "Source" video archived safely somewhere in TDF infra - Inclusion of extra source materials (e.g. talking points used to make the video, example docs displayed or demonstrated during the video, etc..) with the archived source video to help others who may wish to edit or reshoot the content - Ability to Download or view video using only Free Software (Archive.org?) - Strong encouragement for any cross-platform content to be demonstrated using the Doc Team's preferred Free Software GUI shell [1] It would be great to have subtitles provided for each source video from the get-go, however that's definitely a task that can be handled independently, freeing up video creators to create more videos... Cheers, --R [1] https://wiki.documentfoundation.org/Documentation/Production#Sample_screenshots Also see: https://en.wikipedia.org/wiki/Wikipedia:Software_screenshots -- Robinson Tryon QA Engineer - The Document Foundation LibreOffice Community Outreach Herald qu...@libreoffice.org 802-379-9482 | IRC: colonelqubit on Freenode -- To unsubscribe e-mail to: documentation+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/documentation/ All messages sent to this list will be publicly archived and cannot be deleted
