From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: GNU Guix Video Documentation Date: Sun, 28 Oct 2018 21:19:54 +0100 Message-ID: References: <20181025235334.7ebf5970@alma-ubu> <87efcd5oqn.fsf@elephly.net> <20181026120004.5b99860c@alma-ubu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49501) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGrXc-0002bb-HK for guix-devel@gnu.org; Sun, 28 Oct 2018 16:20:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGrXb-0003wf-OM for guix-devel@gnu.org; Sun, 28 Oct 2018 16:20:08 -0400 In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Laura Lazzati Cc: Guix-devel , Ricardo Wurmus Hello Laura, Laura Lazzati ezt =C3=ADrta (id=C5=91pont: 201= 8. okt. 28., V, 20:15): > First, we need to know which have the highest priorities, the > promoting, the howtos, and belonging to which topic(s). And in case > both (the ones "promoting" as well as the "howtos" are equally needed, > I believe that maybe the screencasted one is more appealing, even > taking into account that they are difficult to translate or update if > they get stale, but it also implies in the worst case creating only > one 3 minutes lenght video again on each topic. > And then, for the "howtos", I don't know how many 3 minutes length > videos will be required for each topic, or the depth of them but the > non-screencasted I believe is better, as most of you mentioned. > But I kind need to know which are more important at least for now. > Recall I am new to Guix :) I believe one of the most important part of this discussion is to set these priorities. It might worth to start a new thread for explicitly this, but we can also keep the discussion here. What do you think would be preferable? > I still have to do more research on texinfo, I read the Reference > Guide, but maybe even the slides can be generated with it -LaTex has > Beamer, for instance, there has to be something similar to it. LaTex and Beamer are prefectly acceptable, especially if you are already familiar with them. (You will need texinfo to work with the manual) Also, currently texinfo lacks some translation capabilities, you can ask Julien Lepiller (a.k.a. roptat) on the status of these, but as = we control the whole process here, these might be ignored. I am think about generating code, tests and documentation from the same source for a while, but that is a whole new story :-) > > It would be nice to have the ability to translate on demand in the futu= re. > > The second version of the graph I have posted is created with keeping > > that in mind, that is one of the reasons why it has so many selection a= nd > > composition steps. (Another reason is to have a versitality of outputs)= . > Great. I don't know if the translations will be automated and with > which tools - Ricardo mentioned that the non screencasted had, among > the benefits, easier translations, but I don't know up to which point > they will be automated. I read about the tools for the localization > of the command line commands, but the audios and text (both subtitles > and the slides) will be that easy to translate with scripts? That's > why I though about texinfo- i don't know if by slideshow you mean the > non-GNU slideshow or any other tool. The audio translation would have to be done using a recording, video+audio of a narrator, we can't actually do any better :-) The only thing I propose here, is to break down the recoding to short cuts, so that we can do this in smaller parts. That's why I presented this part as a 'set of clips' in my description. The subtitles translation can be done using a base subtitle file/ subttile database and a separate set of translation files. That way the translations can simply be sent to translators, and work can be parallelized, like it is done for guix, and the manual. Best regards, g_bor