Vertalen van terminalcommando-uitkomsten
Sam Segers
sam.sgrs op gmail.com
Zo Mrt 6 16:31:26 UTC 2016
Ik heb ook al eens zo'n probleem tegen gekomen:
https://bugs.launchpad.net/ubuntu/+source/fakeroot/+bug/1290069
Ik vind dat dit soort problemen de fout is van diegene die dit soort
scripts maakt. Voor OK bestaat de return code ($?). Deze is 0 als alles OK
is.
Heb het net getest bij OK is $? 0. Als het bestand niet bestaat is deze 1.
Dus ik zeg vertalen en de OP op xda informeren over $?
De fout in fakeroot is dan in aangepast om niet op de output te vertrouwen.
Als er een vertaling op launchpad staat mag je die naar mijn mening ook
vertalen. Iemand die grep op stdout doet, moet weten dat dit niet de aan te
raden manier is. Zeker niet als het vertaalbare regels zijn.
Mvg
Sam Segers
Op 6 mrt. 2016 11:44 schreef "Timo Diedering" <timo.diedering op hccnet.nl>:
> On zondag 6 maart 2016 11:28:18 CET Pjotr Vertaalt wrote:
> > Mee eens! In welk pakket zit die overbodige vertaling eigenlijk?
> >
> > Op 6 maart 2016 09:30 schreef Timo Diedering <timo.diedering op hccnet.nl>:
> > > Besten,
> > >
> > > Ik zag vandaag dit draadje:
> > > https://forum.ubuntu-nl.org/index.php?topic=96314.
> > > Daarin is met name het laatste deel interessant:
> > >
> > > "Merk op dat door het ijverige vertaalwerk van het Ubuntu-NL
> vertaalteam
> > > bepaalde opdrachten van de Engelstalige documentatie niet meer werken.
> > >
> > > Bijvoorbeeld:
> > >
> > > sha256sum -c SHA256SUMS 2>&1 | grep OK
> > >
> > >
> > > Geeft GEEN OK! Ook deze opdracht moet worden vertaald als:
> > >
> > > sha256sum -c SHA256SUMS 2>&1 | grep goed"
> > >
> > > Kortom, een terminalcommando geeft niet meer de verwachte uitvoer,
> omdat
> > > die
> > > vertaald is. Ik vraag me af, zeker bij dit soort gevallen, hoe
> wenselijk
> > > dat
> > > is. Het lijkt mij beter om, zeker in het geval van korte uitvoer als
> OK,
> > > dat
> > > overtaald te laten. Bij bijvoorbeeld APT vind ik het iets anders, daar
> > > krijg
> > > je immers geen uitvoer die je snel zou *willen* afvangen met grep.
> > > Hetzelfde geldt voor bijvoorbeeld lspci. Stel, ik wil weten wat mijn
> > > geluidskaart is, dan tik ik in 'sudo lspci | grep audio', het zou
> eerlijk
> > > gezegd niet in mij opkomen dan 'geluid' te moeten gebruiken. Deze
> uitvoer
> > > hebben we dan ook niet vertaald. Het lijkt mij verstandig, om dat niet
> > > vertalen van diagnostische of zeer korte uitvoer als standaard te
> nemen.
> > >
> > > Graag hoor ik ook jullie meningen hierover.
> > > --
> > > Met vriendelijke groet,
> > > Timo Diedering
> > >
> > > --
> > > Ubuntu-l10n-nl mailing list
> > > Ubuntu-l10n-nl op lists.ubuntu.com
> > > Instellingen of uitschrijven:
> > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-l10n-nl
> Ik zie nu dus de volgende wijziging in het bericht: "
> edit: de vertaling van coreutils komt niet van Ubuntu-nl vertaalteam". Ik
> heb
> de string maar wel aangepast voor Xenial naar OK, dus in de volgende versie
> zit de fout niet meer, als het goed is. Niettemin kan het wel een idee
> zijn om
> alle vertalingen even langs te lopen van de coreutils, om te controleren
> of er
> niet meer van deze 'overijverige' vertalinkjes tussen zitten. :-)
>
> De link naar de vertalingen voor Xenial is: https://
>
> translations.launchpad.net/ubuntu/xenial/+source/coreutils/+pots/coreutils/nl/
> +translate?batch=10&show=all&search=
> --
> Met vriendelijke groet,
> Timo Diedering
>
> --
> Ubuntu-l10n-nl mailing list
> Ubuntu-l10n-nl op lists.ubuntu.com
> Instellingen of uitschrijven:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-l10n-nl
>
------------- volgend deel ------------
Een HTML-bijlage is gescrubt...
URL: <https://lists.ubuntu.com/archives/ubuntu-l10n-nl/attachments/20160306/6b423598/attachment.html>
Meer informatie over de Ubuntu-l10n-nl
maillijst