Closed Bug 291678 Opened 19 years ago Closed 19 years ago

bug voor het melden van fouten in 1.1+ nl

Categories

(Mozilla Localizations :: nl / Dutch, defect)

Product:
Mozilla Localizations
Component:
nl / Dutch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mad_maks, Unassigned)

References

(
URL
)

Details

Attachments

(33 obsolete files) 

Meld in deze bug al de fouten die je gevonden hebt in de 1.1+ versie van Firefox
nl. Als het kan graag met een patch.

MM
Blocks: 289795
Summary: bug voor het melden van fouten in 1.1+ → bug voor het melden van fouten in 1.1+ nl
Gisteren heb ik de eerste vertaalde Linux-versie gedownload en ik heb de
grooste fouten die ik ontdekte met deze patch opgelost. Het gaat om fouten voor
accesskeys, spellingskwesties en een XML-fout bij het instellen van de
lettertypen. Daarnaast ook nog wat dingen vertaald die nog in het Engels waren
en heb ik de namen van de tabbladen in het Privacy-paneel ingekort.

Dingen die nog meer opgelost moeten worden:
* Afbeeldingen in browser\searchplugins moeten opnieuw in CVS geplaatst worden
(zelfde probleem als helpafbeeldingen). De zoekplugins hebben nu geen eigen
pictogram.
* Help > Promote Firefox is nog in het Engels. Ik kan zo niet zien wat het
probleem is
* De helpinhoud mist, behalve de introductiepagina
Ik zie dat er nog steeds regelmatig 'lokatie' te vinden is.  Dit moet wel
degelijk 'locatie' zijn.  (Concreet in toolkit/installer/windows/install.it,
lijn 65)  Ik maak hier geen patch van, omdat het waarschijnlijk met een scriptje
overal vervangen moet worden. Opgepast, 'lokaal' en alle afgeleide woorden zijn
met 'k', 'locatie' en afgeleide zijn met 'c'.
(In reply to comment #1)
> Created an attachment (id=182564) [edit]
> Oplossingen voor eerste problemen
> 
> Gisteren heb ik de eerste vertaalde Linux-versie gedownload en ik heb de
> grooste fouten die ik ontdekte met deze patch opgelost. Het gaat om fouten voor
> accesskeys, spellingskwesties en een XML-fout bij het instellen van de
> lettertypen. Daarnaast ook nog wat dingen vertaald die nog in het Engels waren
> en heb ik de namen van de tabbladen in het Privacy-paneel ingekort.

Patch is in de CVS

> Dingen die nog meer opgelost moeten worden:
> * Afbeeldingen in browser\searchplugins moeten opnieuw in CVS geplaatst worden
> (zelfde probleem als helpafbeeldingen). De zoekplugins hebben nu geen eigen
> pictogram.

opgelost

> * Help > Promote Firefox is nog in het Engels. Ik kan zo niet zien wat het
> probleem is
> * De helpinhoud mist, behalve de introductiepagina

Dat klopt, het maken van de nl help had ik uitgezet omdat het leek dat wat ik
ook veranderde het een error veroorzaakte bij het bouwen. Nu de fout ergens
anders bleek te liggen en we een eerste build hebben heb ik het weer aangezet.
In de build van vanavond zou het weer aanwezig moeten zijn.
Attachment #182564 - Attachment is obsolete: true
Attached patch More improvements (obsolete) — — Splinter Review 
Ik merkte toen ik de vertaling in een Windows trunkbuild gezet heb dat ik nog
was verkeerde accesskeys heb laten zitten. In deze patch moet alles goed werken
en heb ik daarnaast ook het formaat goed aangepast voor Windows en Linux. Ook
Firefox aanbevelen moet nu goed in het Help menu werken, deze regel was ook
verplaatst.
Kunnen we vanaf 1.1:
  intl.accept_languages=nl, nl-be, en-us, en
... wijzigen in:
  intl.accept_languages=nl,en

Ik stel ook voor dat we een grote search en replace door de hele source doen,
voor gevallen zoals "locatie", maar ook karakter referenties waar we gewoon
gelijk het goede karakter willen gebruiken. Dit moet 1 persoon doen en in de
tijd moeten er uiteraard geen andere wijzigingen gedaan worden...
Comment on attachment 182580 [details] [diff] [review]
More improvements

toegepast
Attachment #182580 - Attachment is obsolete: true
(In reply to comment #5)
> Kunnen we vanaf 1.1:
>   intl.accept_languages=nl, nl-be, en-us, en
> ... wijzigen in:
>   intl.accept_languages=nl,en

gewijzigt in intl.accept_languages=nl, en-us, en

> 
> Ik stel ook voor dat we een grote search en replace door de hele source doen,
> voor gevallen zoals "locatie", maar ook karakter referenties waar we gewoon
> gelijk het goede karakter willen gebruiken. Dit moet 1 persoon doen en in de
> tijd moeten er uiteraard geen andere wijzigingen gedaan worden...

ik stel voor maak een patch :-) vanuit de versie die nu in de cvs staat.



    
    

    
  
Comment on attachment 182585 [details] [diff] [review]
die patch (fixed locatie + ’)

toegepast.

er was een hunk bij:
-help/firebird-toc.rdf
-help/tabbed_browsing.xhtml
-update/update.dtd

        Attachment #182585 -
        Attachment is obsolete: true

    
    

    
  
De grootte van het voorkeurenvenster is nu aangepast zodat alle tabbladen
zichtbaar zijn.

voor de mensen die een windowsversie willen maken:
-installeer de engelse versie (zip of setup)
-download de nl linux versie en kopieer nl.jar, nl.manifest naar de map chrome
-verander in /defaults/pref/firefox-l10n.js: pref("general.useragent.locale",
"en-US") in pref("general.useragent.locale", "nl")

Als het goed is start Firefox dan in het nederlands op.

    
    

    
  
JanT opmerkingen uit het forum zijn verwerkt

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Kleine dingen.. (obsolete)
        — 
          — Splinter Review
      

    


  
Kleine verbeteringen voor foutjes die ik gister opmerkte rond het blokkeren van
popups. Daarnaast ook een correctie van 1 mailbestand dat me opviel na het
aanpassen van de UserAgent daar.

Over de useragents moeten moeten we trouwens nog een oplossing voor vinden. De
Useragent moet nu 'nl' zijn om de Nederlandse taal in trukbuilds te gebruiken,
maar alle vertaalde extensies gaan uit van 'nl-NL'. Zo werken vertaalde
extensies niet en krijg je de Engelse versie te zien.
Als we general.useragent.locale op nl-NL laten staan levert dat in de complete
Nederlandse versies misschien geen problemen op, maar ik verwacht wel met
taalpakketten die automatisch door Mozilla gegenereerd zullen worden (en van
taalcode nl uitgaan). Een mogelijke oplossing zou zijn dat als de useragent nl
bevat ook nl-NL geaccepteerd zal worden (en eventueel ook nl-BE).

    
    

    
  
Gert-Paul, volgens verschillende RFCs hoort dat inderdaad zo te werken. Als
nl-NL extensies niet op nl werken moet daar een bug voor komen die
waarschijnlijk ook voor andere locales geldt.

    
    

    
  
Comment on attachment 182673 [details] [diff] [review]
Kleine dingen..

patch toegepast behalve:
-general.useragent.locale=nl
+general.useragent.locale=nl-NL

dit moet volgens mij nu nl blijven

        Attachment #182673 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        fixed nog meer &# (obsolete)
        — 
          — Splinter Review
      

    


  
Ik wil er ook nog een maken om " (wanneer er een sluit-" is) om te
zetten in de "curly"-equivalent.

    
    

    
  


  
Gisteren ontdekte ik dat de knoppen in wizards op Linux leegwaren en deze patch
lost dat op.

Ik heb verder trouwens bug 293129 aangemaakt voor het probleem met die
extensies en op www.mozilla-nl.org/vertalen/trunk staat nu documentatie hoe
mensen Tortoise kunnen gebruiken om mee te helpen aan de vertaling.

    
    

    
  


  

        Attachment #182773 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 182772 [details] [diff] [review]
fixed nog meer &#

patch uitgevoerd

        Attachment #182772 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 182844 [details] [diff] [review]
Meer dingen, ook opmerkingen van JanT

patch uitgevoerd

        Attachment #182844 -
        Attachment is obsolete: true

    
    

    
  
Als ik op linux de laatste Firefox 1.1+ in het nederlands wil bouwen krijg ik
foutmeldingen
mijn cvs commando: 
make -f client.mk checkout MOZ_CO_PROJECT=mail,browser MOZ_CO_LOCALES="en-US nl"
daarna export MOZCONFIG=.mozconfig.firefox

de ingoud van .mozconfig.firefox
--------------------------------
mk_add_options MOZ_CO_PROJECT=browser
mk_add_options MOZ_CO_LOCALES="en-US nl"
mk_add_options MOZ_CO_MODULE=mozilla/other-licenses/libart_lgpl
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-firefox

ac_add_options --enable-application=browser
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-ui-locale="en-US"
ac_add_options --enable-ui-locale="nl"
ac_add_options --enable-xft
ac_add_options --enable-svg
ac_add_options --enable-svg-renderer=libart
ac_add_options --disable-freetype2
ac_add_options --enable-optimize=-O
ac_add_options --disable-debug
ac_add_options --prefix=/opt/mozilla
ac_add_options --enable-xft
ac_add_options --disable-tests
---------------------------
daarna het commando 
make -f client.mk build -s

krijg ik op het einde:
Creating ../../../dist/include/accessibility
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
Couldn't GC any strings, exiting.
+++ making chrome /home/nathan/devel/mozilla/netwerk/resources  =>
../../dist/bin/chrome/comm.jar
+++ updating chrome ../../dist/bin/chrome/installed-chrome.txt
+++ overriding content/necko/contents.rdf
updating: content/necko/contents.rdf (stored 0%)
+++ making chrome /home/nathan/devel/mozilla/netwerk/locales  =>
../../dist/bin/chrome/nl.jar
error: file '../../../l10n/nl/netwerk/necko.properties' doesn't exist at
../../config/make-jars.pl line 428, <STDIN> line 4.
gmake[4]: *** [libs] Fout 2
gmake[3]: *** [libs] Fout 2
gmake[2]: *** [tier_9] Fout 2
make[1]: *** [default] Fout 2
make: *** [build] Fout 2
-------------------------

Ook de laatste extensie installeren werkt, bij het heropstarten van firefox
krijg ik een foutmelding: "Extension can not be isntalled, Chrome registration
failed."
Het nederlandse langpack staat wel in mijn extensies

Groeten
Nathan Samson

    
    

    
  
(In reply to comment #20)
 
> de ingoud van .mozconfig.firefox

> ac_add_options --enable-ui-locale="en-US"
> ac_add_options --enable-ui-locale="nl"

ik heb er niet zo veel verstand van maar moet je niet alleen nl als ui locale
activeren ( ik weet wel dat je en-US en nl moet pullen om het bouwen te starten,
zoals je doet)

vraag het eens in het #l10n irc channel

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Kleine dingen (obsolete)
        — 
          — Splinter Review
      

    


  
Tijdens het veranderen van de helpdocumentatie vond ik nog wat foutjes in de
vertaling. Heb deze veranderen maar los gemaakt van de patch voor de help.

    
    

    
  
Comment on attachment 183060 [details] [diff] [review]
Kleine dingen

toegepast

        Attachment #183060 -
        Attachment is obsolete: true

    
    

    
  
je mag er blijkbaar maar ייn selecteren + cvs commando is
make -f client.mk checkout MOZ_CO_PROJECT=mail,browser MOZ_CO_LOCALES=en-US,nl

nu kan ik beginnen de nl versie te testen

(In reply to comment #21)
> (In reply to comment #20)
>  
> > de ingoud van .mozconfig.firefox
> 
> > ac_add_options --enable-ui-locale="en-US"
> > ac_add_options --enable-ui-locale="nl"
> 
> ik heb er niet zo veel verstand van maar moet je niet alleen nl als ui locale
> activeren ( ik weet wel dat je en-US en nl moet pullen om het bouwen te starten,
> zoals je doet)
> 
> vraag het eens in het #l10n irc channel

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Verbeteringen (obsolete)
        — 
          — Splinter Review
      

    


  
Kleine verbeteringen. Van het goed veranderen van de naam Firefox naar Deer
Park, wat accesskeys in de reportertool en een zinnetjes in de opties.

    
    

    
  
(In reply to comment #25)
> Created an attachment (id=184752) [edit]
> Verbeteringen
> 
> Kleine verbeteringen. Van het goed veranderen van de naam Firefox naar Deer
> Park, wat accesskeys in de reportertool en een zinnetjes in de opties.

Op de plek waar jij de naamsverandering doorvoerd is het ook nog niet gebeurt in
de engelse versie. blijkbaar gebruikt de engelse versie de other-licences dir
(nog) niet, daarom had ik het in NL nog niet verandert. zal vandaag eens
informeren wat nu de bedoeling is.

    
    

    
  
Comment on attachment 184752 [details] [diff] [review]
Verbeteringen

Patch is toegepast behalve de naamsverandering. Het is nog niet duidelijk hoe
het gaat werken met de l10n versies.

        Attachment #184752 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Allerlei verbeteringen (obsolete)
        — 
          — Splinter Review
      

    


  
Zoals beloofd.. ;)
Vooral grammaticale zaken aangepast met hier en daar een tekstoptimalisatie,
waar van toepassing een stukje vertaling en waar nodig enkele access keys.

    
    

    
  
(In reply to comment #28)
> Created an attachment (id=185076) [edit]
> Allerlei verbeteringen
> 
> Zoals beloofd.. ;)
> Vooral grammaticale zaken aangepast met hier en daar een tekstoptimalisatie,
> waar van toepassing een stukje vertaling en waar nodig enkele access keys.
> 

Gert-Paul e.a. willen jullie eens kijken naar deze patch, ik heb het gevoel dat
er veranderingen inzitten die we eerder de anderekant op hebben gedaan.

MM

    
    

    
  
(In reply to comment #29)
> Gert-Paul e.a. willen jullie eens kijken naar deze patch, ik heb het gevoel dat
> er veranderingen inzitten die we eerder de anderekant op hebben gedaan.

Ik heb de patch vlug doorgeken (kan niet anders met 3790 regels) en hij ziet er
over het algemeen goed uit en lost zaken op die mij nog niet eerder opgevallen
waren. Ook sommige teksten aangepast zodat deze beter in 1.1 pasten, bv  in
Update tabblad.

Er zijn wel wat dingen waar ik over twijfel:
28:
-<!ENTITY helpContents.label       "Helpinhoud">
+<!ENTITY helpContents.label       "Help-inhoud">
-> Helpinhoud is volgensmij gewoon goed

44:
-<!ENTITY javaScriptConsoleCmd.label   "Javascript-console">
+<!ENTITY javaScriptConsoleCmd.label   "JavaScript-console">
-> We hebben opzich voor Javascript zonder de extra hoofdletter gekozen. Als je
argumenten hebt om het terug te veranderen horen we die graag

343:
-<!ENTITY  proxyTitle.label              "Proxies voor toegang tot het internet
instellen">
+<!ENTITY  proxyTitle.label              "Proxy’s voor toegang tot het internet
instellen">
-> Proxies geeft meer resulaten op Nederlanse pagina's als Proxy's. Klopt dat?

369;
-<!ENTITY  enableJavaScript.label            "Javascript inschakelen">
+<!ENTITY  enableJavaScript.label            "JavaScript inschakelen">
-> Zelfde als bij 44

637:
+<!ENTITY items.label                  "Opschoon-items">
--> Opschoonitems? Je gebruikt wel Opschooninstellingen. Als we dit toch beter
vinden moeten we ook daar een - gebruiken. (r619)

903:
+  <h3 id="help_contents">Help-inhoud</h3>
-> Zelfde als 28

1041:
+    bijbehorende tab te klikken.</p>
-> tabblad

1685:
-<!ENTITY reportForm.behind_login.accesskey          "P">
+<!ENTITY reportForm.behind_login.accesskey          "W">

1694:
-<!ENTITY reportForm.describe.accesskey              "D">
+<!ENTITY reportForm.describe.accesskey              "P">
-> Bovenstaande regels zijn al meegenomen in vorige patch. Moeten er dus uit. Je
zou met Tortoise de code nog eens bij moeten werken. Dit levert zometeen
conflicten op bij het toepassen.

1813:
-CertDumpSubject=Betreft
-CertDumpRDN=Relatief goede naam
+CertDumpSubject=Houder
+CertDumpRDN=Relative Distinguished Name
-> Vertaling van Subject is Houder? Ik ben niet thuis met die termen, maar het
klinkt raar.

, en
-> komt 9x voor. De komma weg in zo'n geval.

ge\u00FCpdatet
--> waarom niet bijgewerkt gebruiken? In de extensiebeheerder gebruiken we wel
Bijwerken. We moeten hier consistent in zijn eventueel de extensiebeheerder
anders ook aanpassen.

    
    

    
  
+1 voor bijgewerkt ipv geupdate :).

~Grauw

    
    

    
  
Het is proxy's volgens de Van Dale.
 <http://www.vandale.nl/opzoeken/woordenboek/?zoekwoord=proxy>

Iemand enig idee of het Groene Boekje wat anders hierover zegt? (Denk aan
'locatie'.)

    
    

    
  
En +1 voor Javascript (kleine letter). Wat proxies betreft, altijd lastig met
leenwoorden :). Maar baby wordt baby’s, dus volgens mij is dat de juiste manier
om een Engels leenwoord naar meervoud om te zetten.

Ik heb mijn vraagtekens bij het vertalen van schedule als ‘rooster’. Is iets met
‘agenda’ of ‘plannen’ niet beter? Maargoed, dat is een aparte issue.

’s dinsdags --> dinsdags
Waarom? Ik heb mijn twijfels of dit correct is, en het ziet er zeker niet
consistent uit. Liever niet, dus.

Je hebt in nl/toolkit/installer/unix/install.it twee regels verwijderd. Ben je
er zeker van dat dit klopt?

Verder zeer goede patch.


~Grauw

    
    

    
  
(In reply to comment #30)
> Ik heb de patch vlug doorgeken (kan niet anders met 3790 regels) en hij ziet er
> over het algemeen goed uit en lost zaken op die mij nog niet eerder opgevallen
> waren. Ook sommige teksten aangepast zodat deze beter in 1.1 pasten, bv  in
> Update tabblad.
> 

Hij is van top tot teen nagelopen dus dat kan kloppen. ;) Maar misschien heb ik
toch nog dingen over het hoofd gezien?

> Er zijn wel wat dingen waar ik over twijfel:
> 28:
> -<!ENTITY helpContents.label       "Helpinhoud">
> +<!ENTITY helpContents.label       "Help-inhoud">
> -> Helpinhoud is volgensmij gewoon goed
> 

'Helpinhoud' had ik eerder voorgesteld maar ik heb nu sterke twijfels, of
eigenlijk juist niet. 'Help-inhoud' is een soort van gelegenheidssamenstelling
waarvan het deel Help eigenlijk niet bestaat (Men zegt wel 'de help', maar
eigenlijk bestaat 'help' niet zelfstandig; dit zou eerder gezien moeten worden
als 'helpfunctie'). MS gebruikt, misschien om dezelfde reden, ook 'Help-inhoud'
en dit is veel duidelijker, en niet alleen voor IE-gebruikers. 'Helpinhoud' doet
qua klank ook denken aan 'helping hand' o.i.d., m.a.w. een deelstreep zou op
zijn plaats zijn. Maar misschien wel de belangrijkste reden: in een normale
samenstelling zegt het eerste deel iets over het laatste, en niet andersom. In
dit geval is immers geen sprake van help van of voor een inhoud, maar inhoud van
de help. Vandaar dat termen als 'helpbestanden' en 'helpfunctie' zo gebleven zijn.

> 44:
> -<!ENTITY javaScriptConsoleCmd.label   "Javascript-console">
> +<!ENTITY javaScriptConsoleCmd.label   "JavaScript-console">
> -> We hebben opzich voor Javascript zonder de extra hoofdletter gekozen. Als je
> argumenten hebt om het terug te veranderen horen we die graag
> 

De kleine letter is dacht ik ook een eerder voorstel van mij geweest. De
gedachte was toen dat het net zo'n woord als 'proxyscript' was maar ik weet nu
dat JavaScript een (merk)term is die wellicht vanwege het niet-onbelangrijke
onderscheid met Java vrijwel overal met een grote S wordt geschreven, en ik denk
dat het verstandig is dat gewoon te volgen.

> 343:
> -<!ENTITY  proxyTitle.label              "Proxies voor toegang tot het internet
> instellen">
> +<!ENTITY  proxyTitle.label              "Proxy’s voor toegang tot het internet
> instellen">
> -> Proxies geeft meer resulaten op Nederlanse pagina's als Proxy's. Klopt dat?
> 

Kan kloppen maar dat zegt natuurlijk niks :). Ik dacht dat het tot voor kort
gebruikelijk was om de Engelse spelling aan te houden, maar inderdaad is net als
bij 'baby's' een apostrof na 'y' tegenwoordig de regel, zelfs bij overgenomen
Engelse woorden.

> 369;
> -<!ENTITY  enableJavaScript.label            "Javascript inschakelen">
> +<!ENTITY  enableJavaScript.label            "JavaScript inschakelen">
> -> Zelfde als bij 44
> 

Idem. Alle termen die zijn gewijzigd zijn overigens globaal meegenomen, ook in
helpteksten.

> 637:
> +<!ENTITY items.label                  "Opschoon-items">
> --> Opschoonitems? Je gebruikt wel Opschooninstellingen. Als we dit toch beter
> vinden moeten we ook daar een - gebruiken. (r619)
> 

Wat voor het ene woord geldt hoeft in het geval van deeltekens niet voor het
andere te gelden, toch? :) Het was hier bedoeld ter bevordering van de
leesbaarheid, te meer daar 'items' een overgenomen Engelse term is en de
[ai]-klank voor sommigen misschien niet meteen duidelijk is.
'Opschooninstellingen' vond ik nog toelaatbaar, alhoewel daarbij mede vanwege
verwarring met 'schoning' bij lezen en tevens het niet zo vaak voorkomen van een
samenstelling die met 'opschoon' begint, een streepje niet zou misstaan.
Taalkundig gezien echter is het zonder streepje wel juist (evenals bijv.
'proxyinstellingen') en om dezelfde reden zou ik ook liever 'opschoonitems'
zien. Als dit lelijk of moeilijk gevonden wordt zou je nog aan 'op te schonen
items' kunnen denken, maar dat vond ik wat ontwijkend en te ver afstaand van het
origineel en het impliceert bovendien een op dat moment uit te voeren taak,
terwijl het om algemeen geldende instellingen gaat.

> 903:
> +  <h3 id="help_contents">Help-inhoud</h3>
> -> Zelfde als 28

idem

> 
> 1041:
> +    bijbehorende tab te klikken.</p>
> -> tabblad

You got me there..

> 
> 1685:
> -<!ENTITY reportForm.behind_login.accesskey          "P">
> +<!ENTITY reportForm.behind_login.accesskey          "W">
> 
> 1694:
> -<!ENTITY reportForm.describe.accesskey              "D">
> +<!ENTITY reportForm.describe.accesskey              "P">
> -> Bovenstaande regels zijn al meegenomen in vorige patch. Moeten er dus uit. Je
> zou met Tortoise de code nog eens bij moeten werken. Dit levert zometeen
> conflicten op bij het toepassen.
> 

Ik had jouw patch wel op tijd gezien en zowel een lokale onaangetaste cvs-kopie
als het bewuste bestand daarop aangepast, maar blijkbaar was dit niet de juiste
manier, vermoedelijk door de oude tijdstempel in de bewerkte kopie?

> 1813:
> -CertDumpSubject=Betreft
> -CertDumpRDN=Relatief goede naam
> +CertDumpSubject=Houder
> +CertDumpRDN=Relative Distinguished Name
> -> Vertaling van Subject is Houder? Ik ben niet thuis met die termen, maar het
> klinkt raar.
> 

Ik ook niet echt en moest even zoeken naar juiste vertalingen ervan, maar het
komt erop neer dat een 'subject' zowel een persoon als een organisatie kan zijn,
als ik het goed heb begrepen. Dacht daarom eerst aan 'persoon/organisatie', maar
daardoor zouden de overige termen met 'subject' erin wat lang worden.
'Certificaathouder' schijnt ook goed te zijn, waarvan 'houder' een ingekorte
vorm is die misschien op zichzelf inderdaad wat raar staat maar aangezien het
hier om certificaten gaat leek het me duidelijk genoeg. Van Dale kent overigens
het woord 'subject' wel maar als [1 [taalk.] onderwerp van een zin], vandaar
niet deze keuze. 'Betreft/betreffend(e)' staat naar mijn idee te ver van
'Subject', zowel zelfstandig als in de overige termen. Ik geef nu nu toch weer
de voorkeur aan 'certificaathouder' maar als iemand iets beters weet..?

> , en
> -> komt 9x voor. De komma weg in zo'n geval.
> 

Ik was me ervan bewust maar vind deze regel in sommige gevallen erg onzinnig,
ook vanwege het gebruik dat een zin niet met 'en' of een ander voegwoord kan
beginnen. Het komt nl. vaak genoeg voor dat t.b.v. leesbaarheid, bijzinnen, of
omdat er een duidelijk pauze optreedt wanneer de zin wordt opgelezen een komma
wel degelijk op zijn plaats is (zie bijv. hierboven bij '...IE-gebruikers') en
de voorkeur krijgt boven splitsen. Ik vermoed ook dat het de gemiddelde
gebruiker beter zal bevallen, maar als dit echt uit den boze is zal ik niet
tegensputteren. ;)

> ge\u00FCpdatet
> --> waarom niet bijgewerkt gebruiken? In de extensiebeheerder gebruiken we wel
> Bijwerken. We moeten hier consistent in zijn eventueel de extensiebeheerder
> anders ook aanpassen.

Het ging me nu (nog) even om de grammatica en 'updaten/bijwerken' was 1 van de
zaken die nu nog inconsistent zijn, maar het gebruik van 'bijwerken' als
werkwoord is denk ik inderdaad beter. Let wel: ook volgens Van Dale bestaat
'updaten' en dus zou ik het globale gebruik ervan niet erg vinden, maar voor een
browser en het grote publiek is de combinatie 'bijwerken/updates'
begrijpelijker. Ik heb ook gezien dat in het geval van 'upgraden' voor de
combinatie 'opwaarderen/nieuwe versie' is gekozen, dus ge\u00FCpgraded zal om
dezelfde reden 'opgewaardeerd' moeten worden?

Een 'update' en dus ook 'Op updates controleren' lijkt me echter de mooiste
oplossing voor het zelfstandig naamwoord maar die discussie is misschien elders
al gevoerd. 'Bijwerking' voor 'update' mag dan enigszins kloppen (zij het als
tweede vertaling) maar ik denk ook nog steeds aan medicijnen en misselijkheid
als ik het lees en heb het nog nooit in een andere betekenis gezien, dus ik zou
die term er graag globaal uit halen.

(In reply to comment #33)
> En +1 voor Javascript (kleine letter). Wat proxies betreft, altijd lastig met
> leenwoorden :). Maar baby wordt baby’s, dus volgens mij is dat de juiste manier
> om een Engels leenwoord naar meervoud om te zetten.
>

Zie boven. Ik heb ook jaren de Engelse spelling aangehouden maar leg me neer bij
de officiële Nederlandse.

> Ik heb mijn vraagtekens bij het vertalen van schedule als ‘rooster’. Is iets met
> ‘agenda’ of ‘plannen’ niet beter? Maargoed, dat is een aparte issue.
>

Niet op gelet, maar wat is er mis met 'tijdschema'?

> ’s dinsdags --> dinsdags
> Waarom? Ik heb mijn twijfels of dit correct is, en het ziet er zeker niet
> consistent uit. Liever niet, dus.
>

Volgens de spellingsregels worden dinsdags, donderdags en vrijdags niet met 's
geschreven, zeer waarschijnlijk vanwege de medeklinkervolgorde 'sd' en 'sv'',
dus die moeten in ieder geval worden gewijzigd. 's Zaterdags en 's zondags mogen
ook al zonder, evenals de overige, dus voor consistentie is het wellicht het
beste om alle dagen zonder 's te schrijven. Met opzet niet meegenomen, eigenlijk
om je vraag uit te lokken. ;)

> Je hebt in nl/toolkit/installer/unix/install.it twee regels verwijderd. Ben je
> er zeker van dat dit klopt?
> 

Dit was niet de bedoeling, maar weet je dit wel zeker? Ik kan het niet uit de
patch halen en het gewijzigde bestand zou maar 5 bytes korter moeten worden.


Iets anders: ik heb de apostrof-wijzigingen bij de bestanden die zijn genoemd in
comment #9 door Anne niet meegenomen om (hopelijk) hetzelfde probleem te
voorkomen, maar deze mogen uiteraard niet vergeten worden.

Verder was ik van plan om een aantal opgevallen zaken als inconsistenties en
grammaticale optimalisaties te bespreken in het Mozbrowser-forum. Is dat een
beter idee dan het hier te doen of toch niet?


    
    

    
  
(In reply to comment #34)
> Hij is van top tot teen nagelopen dus dat kan kloppen. ;) Maar misschien heb ik
> toch nog dingen over het hoofd gezien?
Ik heb tot nu toe geen rare dingen opgemerkt die je per ongeluk verkeerd hebt
gedaan.

> 'Helpinhoud' had ik eerder voorgesteld maar ik heb nu sterke twijfels, of
> eigenlijk juist niet. 'Help-inhoud' is een soort van gelegenheidssamenstelling
> waarvan het deel Help eigenlijk niet bestaat (Men zegt wel 'de help', maar
> eigenlijk bestaat 'help' niet zelfstandig; dit zou eerder gezien moeten worden
> als 'helpfunctie'). MS gebruikt, misschien om dezelfde reden, ook 'Help-inhoud'
> en dit is veel duidelijker, en niet alleen voor IE-gebruikers. 'Helpinhoud' doet
> qua klank ook denken aan 'helping hand' o.i.d., m.a.w. een deelstreep zou op
> zijn plaats zijn. Maar misschien wel de belangrijkste reden: in een normale
> samenstelling zegt het eerste deel iets over het laatste, en niet andersom. In
> dit geval is immers geen sprake van help van of voor een inhoud, maar inhoud van
> de help. Vandaar dat termen als 'helpbestanden' en 'helpfunctie' zo gebleven zijn.
IE gebruikt volgensmij gewoon 'Inhoudsopgave en Index' en geen Help-inhoud.
Hoewel ik je redenering wel kan volgen denk ik dat Helpinhoud gewoon goed is
volgens de regels van de Nederlandse taal. Ik zou ook graag de mening van de
rest van het team willen horen, maar dit Helpinhoud heeft mijn voorkeur. Als de
rest liever Help-inhoud heeft dan heb ik daar opzich geen problemen mee.

> > 44:
> > -<!ENTITY javaScriptConsoleCmd.label   "Javascript-console">
> > +<!ENTITY javaScriptConsoleCmd.label   "JavaScript-console">
> > -> We hebben opzich voor Javascript zonder de extra hoofdletter gekozen. Als je
> > argumenten hebt om het terug te veranderen horen we die graag
> > 
> De kleine letter is dacht ik ook een eerder voorstel van mij geweest. De
> gedachte was toen dat het net zo'n woord als 'proxyscript' was maar ik weet nu
> dat JavaScript een (merk)term is die wellicht vanwege het niet-onbelangrijke
> onderscheid met Java vrijwel overal met een grote S wordt geschreven, en ik denk
> dat het verstandig is dat gewoon te volgen.
Het klopt dat het om een merknaam gaat, maar het is pas veranderd in de
trunkversies (volgensmij op verzoek van Anne) omdat opzich een normale term is.
Vanwege het 
> > 343:
> > -<!ENTITY  proxyTitle.label              "Proxies voor toegang tot het internet
> > instellen">
> > +<!ENTITY  proxyTitle.label              "Proxy’s voor toegang tot het internet
> > instellen">
> > -> Proxies geeft meer resulaten op Nederlanse pagina's als Proxy's. Klopt dat?
> > 
> Kan kloppen maar dat zegt natuurlijk niks :). Ik dacht dat het tot voor kort
> gebruikelijk was om de Engelse spelling aan te houden, maar inderdaad is net als
> bij 'baby's' een apostrof na 'y' tegenwoordig de regel, zelfs bij overgenomen
> Engelse woorden.
Klopt. Het is proxy's. Google is op dat moment een snelle indicatie wat goed is
en van Van Dale had ik er niet bijgepakt. Ook het Groene boekje zegt trouwens
proxy's, heb ik later even opgezocht. 
> > 637:
> > +<!ENTITY items.label                  "Opschoon-items">
> > --> Opschoonitems? Je gebruikt wel Opschooninstellingen. Als we dit toch beter
> > vinden moeten we ook daar een - gebruiken. (r619)
> > 
> 
> Wat voor het ene woord geldt hoeft in het geval van deeltekens niet voor het
> andere te gelden, toch? :) Het was hier bedoeld ter bevordering van de
> leesbaarheid, te meer daar 'items' een overgenomen Engelse term is en de
> [ai]-klank voor sommigen misschien niet meteen duidelijk is.
> 'Opschooninstellingen' vond ik nog toelaatbaar, alhoewel daarbij mede vanwege
> verwarring met 'schoning' bij lezen en tevens het niet zo vaak voorkomen van een
> samenstelling die met 'opschoon' begint, een streepje niet zou misstaan.
> Taalkundig gezien echter is het zonder streepje wel juist (evenals bijv.
> 'proxyinstellingen') en om dezelfde reden zou ik ook liever 'opschoonitems'
> zien. Als dit lelijk of moeilijk gevonden wordt zou je nog aan 'op te schonen
> items' kunnen denken, maar dat vond ik wat ontwijkend en te ver afstaand van het
> origineel en het impliceert bovendien een op dat moment uit te voeren taak,
> terwijl het om algemeen geldende instellingen gaat.
Mijn voorkeur heeft heeft denk ik wel Opschoonitems. Dat er dus maar van maken?
> Ik had jouw patch wel op tijd gezien en zowel een lokale onaangetaste cvs-kopie
> als het bewuste bestand daarop aangepast, maar blijkbaar was dit niet de juiste
> manier, vermoedelijk door de oude tijdstempel in de bewerkte kopie?
> 
Je moet via 'CVS bijwerken' in het contextmenu van de Verkenner kiezen voor je
een patch maakt. Misschien dat nog eens proberen als je een nieuwe patch maakt?
> > 1813:
> > -CertDumpSubject=Betreft
> > -CertDumpRDN=Relatief goede naam
> > +CertDumpSubject=Houder
> > +CertDumpRDN=Relative Distinguished Name
> > -> Vertaling van Subject is Houder? Ik ben niet thuis met die termen, maar het
> > klinkt raar.
> > 
> 
> Ik ook niet echt en moest even zoeken naar juiste vertalingen ervan, maar het
> komt erop neer dat een 'subject' zowel een persoon als een organisatie kan zijn,
> als ik het goed heb begrepen. Dacht daarom eerst aan 'persoon/organisatie', maar
> daardoor zouden de overige termen met 'subject' erin wat lang worden.
> 'Certificaathouder' schijnt ook goed te zijn, waarvan 'houder' een ingekorte
> vorm is die misschien op zichzelf inderdaad wat raar staat maar aangezien het
> hier om certificaten gaat leek het me duidelijk genoeg. Van Dale kent overigens
> het woord 'subject' wel maar als [1 [taalk.] onderwerp van een zin], vandaar
> niet deze keuze. 'Betreft/betreffend(e)' staat naar mijn idee te ver van
> 'Subject', zowel zelfstandig als in de overige termen. Ik geef nu nu toch weer
> de voorkeur aan 'certificaathouder' maar als iemand iets beters weet..?
Misschien dat maar doen. Het is iig duidelijker dan houder alleen. Ook de
huidige waarde van
Betreft is niet alles, hoewel ik die ook niet slecht vind.
> 
> > , en
> > -> komt 9x voor. De komma weg in zo'n geval.
> > 
> 
> Ik was me ervan bewust maar vind deze regel in sommige gevallen erg onzinnig,
> ook vanwege het gebruik dat een zin niet met 'en' of een ander voegwoord kan
> beginnen. Het komt nl. vaak genoeg voor dat t.b.v. leesbaarheid, bijzinnen, of
> omdat er een duidelijk pauze optreedt wanneer de zin wordt opgelezen een komma
> wel degelijk op zijn plaats is (zie bijv. hierboven bij '...IE-gebruikers') en
> de voorkeur krijgt boven splitsen. Ik vermoed ook dat het de gemiddelde
> gebruiker beter zal bevallen, maar als dit echt uit den boze is zal ik niet
> tegensputteren. ;)
Ik de meeste gevallen vind ik die extra komma niet veel utimaakt qua
leesbaarheid en daarom kan hij net zo goed wegblijven.

Ik merkte net trouwens wel dat er ook op andere plekken in de patch ', en'
voorkomt, ook op plaatsen die jij niet veranderd hebt. Wat mij betreft mag het
daar dus ook weg, maar ik weet niet of men op die plek het met opzet gebruikt heeft.
> 
> > ge\u00FCpdatet
> > --> waarom niet bijgewerkt gebruiken? In de extensiebeheerder gebruiken we wel
> > Bijwerken. We moeten hier consistent in zijn eventueel de extensiebeheerder
> > anders ook aanpassen.
> 
> Het ging me nu (nog) even om de grammatica en 'updaten/bijwerken' was 1 van de
> zaken die nu nog inconsistent zijn, maar het gebruik van 'bijwerken' als
> werkwoord is denk ik inderdaad beter. Let wel: ook volgens Van Dale bestaat
> 'updaten' en dus zou ik het globale gebruik ervan niet erg vinden, maar voor een
> browser en het grote publiek is de combinatie 'bijwerken/updates'
> begrijpelijker. Ik heb ook gezien dat in het geval van 'upgraden' voor de
> combinatie 'opwaarderen/nieuwe versie' is gekozen, dus ge\u00FCpgraded zal om
> dezelfde reden 'opgewaardeerd' moeten worden?
Opzich is opwaarderen een woord dat een beetje raar klinkt, maar wel beter is
dan geüpgraded.

Ik denk dat we daar dus maar voor moeten komen, of mensen moeten een beter
alternatief hebben.
> Een 'update' en dus ook 'Op updates controleren' lijkt me echter de mooiste
> oplossing voor het zelfstandig naamwoord maar die discussie is misschien elders
> al gevoerd. 'Bijwerking' voor 'update' mag dan enigszins kloppen (zij het als
> tweede vertaling) maar ik denk ook nog steeds aan medicijnen en misselijkheid
> als ik het lees en heb het nog nooit in een andere betekenis gezien, dus ik zou
> die term er graag globaal uit halen.
Bijwerkingen is idd geen goede vertaling, net als Oplichten dat eerst in de
zoekwerkbalk gebruikt werd.
> 
> (In reply to comment #33)
> > En +1 voor Javascript (kleine letter). Wat proxies betreft, altijd lastig met
> > leenwoorden :). Maar baby wordt baby’s, dus volgens mij is dat de juiste manier
> > om een Engels leenwoord naar meervoud om te zetten.
> >
> 
> Zie boven. Ik heb ook jaren de Engelse spelling aangehouden maar leg me neer bij
> de officiële Nederlandse.
> 
> > Ik heb mijn vraagtekens bij het vertalen van schedule als ‘rooster’. Is iets met
> > ‘agenda’ of ‘plannen’ niet beter? Maargoed, dat is een aparte issue.
> >
> 
> Niet op gelet, maar wat is er mis met 'tijdschema'?
Tijdschema lijkt mij beter dan Agenda of Plannen. Misschien kun je dat meenemen
in een verbeterde patch?
> 
> > ’s dinsdags --> dinsdags
> > Waarom? Ik heb mijn twijfels of dit correct is, en het ziet er zeker niet
> > consistent uit. Liever niet, dus.
> >
> 
> Volgens de spellingsregels worden dinsdags, donderdags en vrijdags niet met 's
> geschreven, zeer waarschijnlijk vanwege de medeklinkervolgorde 'sd' en 'sv'',
> dus die moeten in ieder geval worden gewijzigd. 's Zaterdags en 's zondags mogen
> ook al zonder, evenals de overige, dus voor consistentie is het wellicht het
> beste om alle dagen zonder 's te schrijven. Met opzet niet meegenomen, eigenlijk
> om je vraag uit te lokken. ;)
Je moet idd wel consistent zijn. Deze teksten zijn momenteel niet zichtbaar in
Firefox, dus het maakt niet zoveel uit.
Ik heb geen problemen met alles zonder 's, dat dan maar doen?
> > Je hebt in nl/toolkit/installer/unix/install.it twee regels verwijderd. Ben je
> > er zeker van dat dit klopt?
> > 
> 
> Dit was niet de bedoeling, maar weet je dit wel zeker? Ik kan het niet uit de
> patch halen en het gewijzigde bestand zou maar 5 bytes korter moeten worden.
Nee, je hebt niets verwijderd. Probleem is dat er standaard al streepjes voor
die teksten staan. Dan lijkt het of je wat verwijderd hebt :)
> Iets anders: ik heb de apostrof-wijzigingen bij de bestanden die zijn genoemd in
> comment #9 door Anne niet meegenomen om (hopelijk) hetzelfde probleem te
> voorkomen, maar deze mogen uiteraard niet vergeten worden.
>
> Verder was ik van plan om een aantal opgevallen zaken als inconsistenties en
> grammaticale optimalisaties te bespreken in het Mozbrowser-forum. Is dat een
> beter idee dan het hier te doen of toch niet?
> 
Ik vind het niet lekker werken om zo in Bugzilla een heel grote patch door te
spreken. Liever gaan we óf door op MozBrowser, of spreken we met z'n allen een
keer in #mozilla.nl af op irc.mozilla.org. 

Misschien dat het voor die gramaticale zaken wel goed is eerst een overzicht te
maken. Dan kan iedereen eerst een mening daarover vormen.

    
    

    
  
Helpinhoud: daar hebben we ten tijde van 1.0 ook over gediscussieerd, en dit is
de uitkomst daarvan geweest dus ik denk niet dat het veranderd moet worden. Dan
blijven we bezig, wordt het voor Firefox 1.5 weer veranderd in helpinhoud en
voor 2.0 weer in help-inhoud, etc. Laat het dus maar zoals het is.

Tijdschema: graag! Klinkt veel beter.

’s: ikzelf vind het beter zoals het was, maar het maakt me niet echt veel uit.
Zolang het maar consistent het een of het ander is.

Twee verwijderde regels in nl/toolkit/installer/unix/install.it: Die zijn wel
degelijk verwijderd. Kijk maar naar de diff van de patch, waar ze met groen zijn
gemarkeerd.

#mozbrowser.nl: ik ben er een paar keer geweest, maar telkens was er niemand
(actief) die aan de vertaling meewerkt.

Grammaticale zaken overzicht: dat zou ik inderdaad ook graag zien. En als we
over bepaalde dingen beslissen, vergeet het vertaalwoordenboek op de wiki dan
niet :). Ik denk dat dat een goede plek is om de uitkomst van een dergelijke
discussie samen te vatten.


~Grauw

    
    

    
  
p.s. het is 1.0+...

    
    

    
  
nl/toolkit/installer/unix/install.it: Correctie, ze zijn toegevoegd, niet
verwijderd. Ik denk dat ze ondertussen in het CVS eruit zijn gehaald. Daar zal
je dus wanneer je update waarschijnlijk een conflict krijgen.

~Grauw

    
    

    
  
(In reply to comment #36)

> 
> #mozbrowser.nl: ik ben er een paar keer geweest, maar telkens was er niemand
> (actief) die aan de vertaling meewerkt.
> 
oh



    
    

    
  
Comment on attachment 185076 [details] [diff] [review]
Allerlei verbeteringen

graag een nieuwe patch maken met de bovenstaande opmerkingen verwerkt. Let op 
nl/toolkit/chrome/mozapps/extensions/extensions.properties  is vandaag
verandert (een aantal nieuwe regels en de volgorde van de regels is gelijk
gemaakt aan de engelse versie)

        Attachment #185076 -
        Attachment is obsolete: true

    
    

    
  


  
Bovengenoemde zaken aangepast en enkele nieuwe correcties toegevoegd. Ook de 7
niet-gelaagde &8217-gevallen van comment #9 zijn nu meegenomen.

Niet aangepast: overige ', en'-voorvallen en de grote s voor JavaScript, omdat
het laatste naar ik vermoed toch juist is. Op de 2 voorkomende gevallen van een
kleine s na bevatten alle bestanden allemaal een grote S (evenals in andere
talen) en wat er over te vinden is lijkt te bevestigen dat dit klopt. Was die
kleine s wel 100% zeker en wat was de reden ervan? Wellicht handig dus om nu de
zaak consistent te maken (wat de bedoeling was) en indien nodig in een aparte
patch globaal aan te passen.

'Helpinhoud' teruggezet maar met tegenzin, graag nog terugkoppeling. Ondanks
een kleine onjuistheid in mijn eerdere beredenering betreft dit naar mijn idee
toch een geval van een gelegenheidssamenstelling waarbij een koppelstreep
gebruikelijk is (dan wel verplicht), het argument 'ter verduidelijking' al
daargelaten. Ook MS gebruikt niet zonder reden aan 'de Help' refererende termen
als Help-pagina's, Help-onderwerpen, Help-sessie, Help-informatie, Help-viewer
etc. (ook met hoofdletter) en daar valt Help-inhoud ook onder. Lijkt me dus ook
iets voor een volgende patch.

    
    

    
  
Comment on attachment 185425 [details] [diff] [review]
enkele schoonheidsfoutjes, en 'sleuren' -> 'slepen'

Bedankt voor de patch, maar wil je een nieuwe maken zonder: -<!--
+<!--

dit lijkt me een foutje.

    
    

    
  
Comment on attachment 185421 [details] [diff] [review]
Allerlei verbeteringen, aangepast

patch toegepast, bedankt

        Attachment #185421 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Nieuwe teksten FF en meer (obsolete)
        — 
          — Splinter Review
      

    


  
Ik heb vandaag weer een nieuwe nightly geprobeerd en door werk aan de Software
Update misten wat vertalingen. Met deze patch moeten de vertaalde versies weer
goed werken. Omdat sommige teksten ook niet meer in het help-menu verwijderd
zijn heb ik die ook uit het bestand gehaald (net als in het Engels gebeurd is).


Daarnaast ook wat updates voor Thunderbird, hoewel die hier eigenlijk niet
thuishoren. Nav een bericht op de mailinglijst gelijk maar even doorgevoerd
plus dingen die ik daarnaast nog tegenkwam.

    
    

    
  
Ik heb trouwens ook de kleine wijzigingen die met de vorige patch doorgevoerd
moesten worden meegenomen. Dan is dat ook allemaal afgerond en is daarvoor geen
nieuwe patch meer nodig.

    
    

    
  
(In reply to comment #46)
> Ik heb trouwens ook de kleine wijzigingen die met de vorige patch doorgevoerd
> moesten worden meegenomen. Dan is dat ook allemaal afgerond en is daarvoor geen
> nieuwe patch meer nodig.

Ik ben bang voor UTF8-problemen bij schedule.description (ייn) en
copyToFolder.label (כ).
Graag ook 'iets' in de gisteren gewijzigde notification.description behouden.
Overigens gebruikt men hier in de Engelse versie de term 'notification', dus ik
vraag me af of waarschuwen -> waarschuwingsschema wel zo'n goed idee is.

    
    

    
  
Comment on attachment 185552 [details] [diff] [review]
Nieuwe teksten FF en meer

patch toegepast (nog wel een typefoutje eruitgehaald)

        Attachment #185552 -
        Attachment is obsolete: true

    
  

        Attachment #185425 -
        Attachment is obsolete: true

    
    

    
  
extensions/update.properties
extensions/update.dtd
updates/update.properties
updates/imcompatible.dtd
updates/updates.dtd

zijn momenteel in het engels (waarschijnlijk hebben we de string al vertaald
maar moeten ze uit de oude bestanden gehaald worden) zodat (hopelijk)het bouwen
weer begint (bestanden zijn verandert door: "	bug 296868 - Land Software Update
Service on the trunk. Part of ongoing 1.1 feature work. Contains work by Darin
Fisher and myself. This feature does not function yet but should not be
intrusive. Includes first phase of bug 296566 - move extension update into the
Extension Manager") 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Update- & extensions-bestanden (obsolete)
        — 
          — Splinter Review
      

    


  
Bovengenoemde 5 bestanden en kleine gerelateerde zaken.

    
    

    
  
Comment on attachment 185634 [details] [diff] [review]
Update- & extensions-bestanden

dank u, patch is toegepast

    
  

        Attachment #185634 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Kleine correcties (obsolete)
        — 
          — Splinter Review
      

    


  
Correcties in installerbestanden en nog wat kleinigheidjes en access keys.

    
    

    
  
(In reply to comment #52)
> Created an attachment (id=185666) [edit]
> Kleine correcties
> 
> Correcties in installerbestanden en nog wat kleinigheidjes en access keys.

in deze patch maak je van JavaScript weer Javascript en volgens mij was jij
degene die vond dat het JavaScript moest worden.....

    
    

    
  
(In reply to comment #53)
> 
> in deze patch maak je van JavaScript weer Javascript en volgens mij was jij
> degene die vond dat het JavaScript moest worden.....

Goed gezien. ;) Dit zijn de enige twee gevallen waarin het woord in de originele
Engelse tekst (volledig) met kleine letters wordt geschreven (ook in de Franse
overigens maar dat zegt niet altijd alles). In het ene geval waarschijnlijk
omdat het om 'een javascript' gaat, in het andere omdat daarmee het protocol
wordt bedoeld. Ik had ze dus per ongeluk meeveranderd en dit misschien in het
commentaar moeten zetten.



    
    

    
  
Comment on attachment 185666 [details] [diff] [review]
Kleine correcties

ok, patch toegepast

        Attachment #185666 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        spelfouten, Mozilla-ismen... (obsolete)
        — 
          — Splinter Review
      

    


  
Een paar spellingfouten, streepjes en trema's te veel of te weinig, 'bladeren'
door navigeren vervangen...

Één ding stoort me nog: 'rasterpunten': is dit niet gewoon pixels?  Is deze
term niet genoeg in het Nederlandse taalgebruik doorgedrongen?	Want als ik
rasterpunt opzoek in de GVD, wordt ik er niet veel wijzer uit...

    
  

        Attachment #186000 -
        Flags: approval-l10n?

    
    

    
  
Wat dingen waar ik het niet mee eens ben:
- Internet-opties wordt door Internet Explorer gebruikt. Daarom is het
volgensmij goed in deze context, omdat we uit IE importeren
- Een vervanging voor bladergeschiedenis is goed, maar het moet dan wel
navigatiegeschiedenis worden ipv navigeergeschiedenis. Dat laatste klinkt zo raar

Verder is het idd goed om pixels te gaan gebruiken. Thunderbird doet dat al en
het is een heel ingeburgerd woord in Nederland. 
En approval l10n is nu nog niet nodig. We mogen nog alles wijzigingen zonder
toestemmig, dus Tim Maks kan ze zo aan CVS toevoegen.

    
    

    
  
In nl/browser/chrome/browser/preferences/fonts.dtd introduceer je een Unicode
BOM aan het begin van de file (zichtbaar als  in een Latin-1 representatie
zoals hier in Bugzilla). Gelieve die te verwijderen :).

~Grauw

    
    

    
  
En zo zie ik ook een BOM in history.dtd. Weg ermee.

In privacy.dtd vervange je privé door private; hier ben ik het niet mee eens.
Ook de verwijdering van het lidwoord ‘de’ in de entity privacy.intro zie ik niet
als noodzakelijk, ook liever niet dus.

In preferences.properties: "die u wilt toestemming geven" --> "die u toestemming
wilt geven" (2x)

En ik heb ook mijn twijfels over of het "de cookie" of "het cookie" is; de
oorspronkelijke ‘de’ klinkt mij meer natuurlijk in de oren.

Verder ben ik het ook eens met de opmerkingen van Gert-Paul.

    
    

    
  
Is attachment 185425 [details] [diff] [review] wel eens toegepast? Met verwijdering van de BOM lijkt hij
me verder prima.

~Grauw

    
    

    
  
Wil ook niet te kritisch klinken maar 'Internet-opties' is inderdaad OK bevonden
om bovengenoemde reden, 'de cookie' is technisch juist (ook al klinkt het
onwerkelijk), 'typen' is globaal gekozen boven 'types', 'die u wilt toestemming
geven' kan beter (omdraaien), 'site' is globaal 'website', nog eens 'toestemming
wilt geven', nog 3x 'typen', 'u moet het maar' klinkt misschien beter maar is
zeker niet wat bedoeld wordt, en 'private' is er ook globaal uitgehaald, althans
voor 'sleutel' (maar kan op zich wel). Eens met 'bladergeschiedenis'.

    
    

    
  
"‘site’ is globaal ‘website’": Dan is de volgende regel inconsistent en moet die
in plaats daarvan aangepast worden:

popuppermissionstitle=Toegestane sites - Popupvensters

En zo ook bij downloadpermissionstitle. Misschien zijn er nog wel meer
voorkomens in dezelfde omgeving.

Persoonlijk maakt het mij niet zo heel veel uit of er nou sites of websites
gebruikt wordt; de mensen begrijpen het toch wel, en zolang het maar niet
dermate inconsistent is als het nu is vind ik het best om website af en toe
korter als site op te schrijven. Maar ik schik mij naar het algemene besluit :).

Wat een -s of een -n uitgang voor meervoud betreft, even voor de duidelijkheid:
beiden zijn correct voor woorden zoals ‘type’ in de Nederlandse taal, dus op
zich was je verandering niet foutief; er was echter ook geen reden tot verandering.

masterPassword.intro ik snap de intentie van de verandering, maar ik stel voor
de oorspronkelijke tekst te nemen, met de volgende aanpassing: "eens" ->
"eenmaal". Ook stel ik voor de - door een , te vervangen.

Wat ‘private’ betreft, "privé-informatie" is een prima en gangbaar Nederlands
woord, private is veel formeler. Ik zie geen reden om deze aanpassing te maken
aangezien de originele tekst niet fout is, en makkelijker weg leest. In het
kader van sleutels vind ik private juist weer een betere term, maargoed.


~Grauw

p.s. wat de BOM betreft, ik kan Notepad2 als tekst editor aanraden, in deze kan
je met File/Encoding goede controle op de aanwezigheid van de BOM uitoefenen, en
hij voegt normaal gesproken ook niet zomaar een BOM toe tenzij je dat expliciet
aangeeft.

    
    

    
  
(In reply to comment #60)
> Is attachment 185425 [details] [diff] [review] [edit] wel eens toegepast? Met verwijdering van de BOM
lijkt hij
> me verder prima.
> 
> ~Grauw

zie comment #43

    
    

    
  
Comment on attachment 186000 [details] [diff] [review]
spelfouten, Mozilla-ismen...

bedankt voor de patch, maar gezien de opmerkingen graag een nieuwe met de
opmerkingen verwerkt of weerlegt.

        Attachment #186000 -
        Attachment is obsolete: true

        Attachment #186000 -
        Flags: approval-l10n?

    
    

    
  
(In reply to comment #58)
> In nl/browser/chrome/browser/preferences/fonts.dtd introduceer je een Unicode
> BOM aan het begin van de file (zichtbaar als  in een Latin-1 representatie
> zoals hier in Bugzilla). Gelieve die te verwijderen :).

Ik merk dat ik dat in een volgende mini-patch ook weer heb, maar krijg dat niet
weg.  Ik gebruik gewoon Notepad hiervoor, want Wordpad geeft inderdaad van die
vreemde tekens, ook voor bv. ë.  Iemand een suggestie voor een betere editor op
Winxp?


    
    

    
  
(In reply to comment #59)
> En zo zie ik ook een BOM in history.dtd. Weg ermee.

Ok maar hoe, zie vorige reply.

> In privacy.dtd vervange je privé door private; hier ben ik het niet mee eens.

Ok, maar dan moet het privéinformatie zijn, en dat ziet er zo lelijk uit.

> Ook de verwijdering van het lidwoord ‘de’ in de entity privacy.intro zie ik niet
> als noodzakelijk, ook liever niet dus.

Maar het om welke informatie gaat het dan?  Als er 'de' staat, dan ga je ervan
uit dat hier al eerder sprake van was, dat is hier niet het geval.

> In preferences.properties: "die u wilt toestemming geven" --> "die u toestemming
> wilt geven" (2x)

Ja.  Moet ik dit zelf nog aanpassen?  Hoe werkt dit hier eigenlijk allemaal?

> En ik heb ook mijn twijfels over of het "de cookie" of "het cookie" is; de
> oorspronkelijke ‘de’ klinkt mij meer natuurlijk in de oren.

De GVD houdt het bij het cookie: cookie het; -s



    
    

    
  
(In reply to comment #62)
> "‘site’ is globaal ‘website’": Dan is de volgende regel inconsistent en moet 

Inderdaad, ik deed het voor de consistentie, maar of het nu website of site is,
maakt niet zo veel uit.

> Wat een -s of een -n uitgang voor meervoud betreft, even voor de duidelijkheid:
> beiden zijn correct voor woorden zoals ‘type’ in de Nederlandse taal, dus op
> zich was je verandering niet foutief; er was echter ook geen reden tot
verandering.

Googlefight leert me dat types met s gangbaarder is.  Waarom zou ik het dan niet
veranderen?  Of is dat zo veel extra werk dan?

> masterPassword.intro ik snap de intentie van de verandering, maar ik stel voor
> de oorspronkelijke tekst te nemen, met de volgende aanpassing: "eens" ->
> "eenmaal". Ook stel ik voor de - door een , te vervangen.

Ja, lijkt me ook beter, evt. "slechts eenmaal", dat is de intentie die ik wou
uitdrukken.

> Wat ‘private’ betreft, "privé-informatie" is een prima en gangbaar Nederlands
Zie Comment #66

En of 'die u wilt toestemming geven' kan beter (omdraaien) waar is, dat is
grotendeels afhankelijk van de streek van herkomst, en daar ik Vlaming ben vind
ik dat goed klinken, maar ik zie er geen probleem in dit aan te passen ;-)

    
    

    
  
(In reply to comment #65)
> (In reply to comment #58)
> > In nl/browser/chrome/browser/preferences/fonts.dtd introduceer je een Unicode
> > BOM aan het begin van de file (zichtbaar als  in een Latin-1 representatie
> > zoals hier in Bugzilla). Gelieve die te verwijderen :).
> 
> Ik merk dat ik dat in een volgende mini-patch ook weer heb, maar krijg dat niet
> weg.  Ik gebruik gewoon Notepad hiervoor, want Wordpad geeft inderdaad van die
> vreemde tekens, ook voor bv. ë.  Iemand een suggestie voor een betere editor op
> Winxp?
> 

ik gebruik crimson editor

    
    

    
  
(In reply to comment #65)
> Ik gebruik gewoon Notepad hiervoor, want Wordpad geeft inderdaad van die
> vreemde tekens, ook voor bv. ë.  Iemand een suggestie voor een betere editor
> op Winxp?

Notepad voegt bij Unicode bestanden automatisch een BOM toe en er is geen manier
om dat te verhinderen. Probeer de door mij al eerder gesuggereerde Notepad2
eens, het is een lichtgewicht editor vergelijkbaar met Notepad, alleen dan met
aanzienlijk meer ‘power’ :), en hij kan goed overweg met Unicode (iets wat
helaas niet van alle editors gezegd kan worden).


> > In privacy.dtd vervange je privé door private; hier ben ik het niet mee eens.
> 
> Ok, maar dan moet het privéinformatie zijn, en dat ziet er zo lelijk uit.

Zeker weten? Privé-gegevens, privé-informatie... dat ziet er vrij normaal uit
(noot: ik doe dit op gevoel ;p).


> > Ook de verwijdering van het lidwoord ‘de’ in de entity privacy.intro zie ik niet
> > als noodzakelijk, ook liever niet dus.
> 
> Maar het om welke informatie gaat het dan?  Als er 'de' staat, dan ga je ervan
> uit dat hier al eerder sprake van was, dat is hier niet het geval.

De voornaamste reden voor mijn bezwaar is dat ‘de’ beter klopt in het stukje
‘bewaart de informatie (...) in de volgende gebieden:’, dat lijkt mij beter te
kloppen.

Als er ‘bewaart informatie (...) in de volgende gebieden’ staat dan wordt er
niet aangegeven wélke informatie (de), terwijl dat in de (...) toch gebeurt...
dat is raar.


> > In preferences.properties: "die u wilt toestemming geven" --> "die u toestemming
> > wilt geven" (2x)
> 
> Ja.  Moet ik dit zelf nog aanpassen?  Hoe werkt dit hier eigenlijk allemaal?

Ja, gewoon nieuwe patch maken met veranderingen die gesuggereerd zijn.


> > En ik heb ook mijn twijfels over of het "de cookie" of "het cookie" is; de
> > oorspronkelijke ‘de’ klinkt mij meer natuurlijk in de oren.
> 
> De GVD houdt het bij het cookie: cookie het; -s

Het groene boekje is de enige authoriteit op dit gebied, de Van Dale heeft
aantoonbaar flinke fouten, dat zijn we vaker tegen gekomen. In dit geval betreft
het een leenwoord dus gaan de regels voor leenwoorden op. Laat ik hier nu geen
goed naslagwerk op mijn kamer hebben liggen waardoor ik dit niet op kan zoeken,
maar voor zover ik weet is het ‘de’. Het komt in ieder geval natuurlijker op mij
over.


(In reply to comment #67)
> > Wat een -s of een -n uitgang voor meervoud betreft, even voor de duidelijkheid:
> > beiden zijn correct voor woorden zoals ‘type’ in de Nederlandse taal, dus op
> > zich was je verandering niet foutief; er was echter ook geen reden tot
> verandering.
> 
> Googlefight leert me dat types met s gangbaarder is.  Waarom zou ik het dan niet
> veranderen?  Of is dat zo veel extra werk dan?

We hebben voor -n gekozen, en beiden zijn correct en gangbaar. Dergelijke kleine
dingen zijn bovendien het niet waard om veranderd te worden, imho. If it ain’t
broken, don’t fix it :).


> En of 'die u wilt toestemming geven' kan beter (omdraaien) waar is, dat is
> grotendeels afhankelijk van de streek van herkomst, en daar ik Vlaming ben vind
> ik dat goed klinken, maar ik zie er geen probleem in dit aan te passen ;-)

Haha, wel, het is absoluut geen ABN, de woordvolgorde is verkeerd ^_^.

In het vlaams worden er wel vaker dingen omgedraaid, zo ook vast en zeker ipv
geen zeker en vast (vlaams), en ook zwart/wit ipv wit/zwart (vlaams).


~Grauw

    
    

    
  
De of het cookie: zie
http://nl.wikipedia.org/wiki/Zelfstandig_naamwoord#Vrouwelijke_woorden.2C_de.28v..29

"woorden met de uitheemse achtervoegsels of elementen; -ie (...)"


~Grauw

    
    

    
  
Ik denk dat je met privéinformatie gelijk hebt. Als het prive-informatie zou
zijn dan moest er wel een streepje tussen, maar doordat het een é en een i
betreft kan het niet verward worden met ‘ei’. Nog altijd veel beter dan private
informatie trouwens :).

~Grauw

    
    

    
  
> Ok, maar dan moet het privéinformatie zijn, en dat ziet er zo lelijk uit.

Woorden met 'privé' krijgen wel degelijk een streepje na de é, ondanks de
verwachting dat er toch geen klinkerbotsing optreedt.

> Googlefight leert me dat types met s gangbaarder is.  Waarom zou ik het dan
niet veranderen?  Of is dat zo veel extra werk dan?

Gebruik nooit Google om te bepalen of iets grammaticaal juist is, zou ik zeggen.
'Typen' is min of meer gekozen omdat ook 'lettertypen' wordt gebruikt en
consistentie is zeker aan te raden. 'Types' wordt dacht ik ook meer gebruikt bij
personen, of doet er i.i.g. aan denken, maar dat terzijde. ;)

>Ja, lijkt me ook beter, evt. "slechts eenmaal", dat is de intentie die ik wou
uitdrukken.

Pas dan wel op dat je 'but you must enter it once per session' niet verwart met
'you must enter it only once per session', dat was de mijne. ;) M.a.w. de nadruk
op die éénmaal is in de oorspronkelijke tekst niet zo groot; er wordt slechts
aangegeven dat het paswoord een algemene bescherming geeft, maar dat het wel een
keer ingevoerd moet worden.

Cookie: Apple, MS en de Linux-wereld etc. gebruiken ook 'de' en ik vrees toch
dat dat 'correcter' is. Wat dat betreft is het jammer dat Van Dale 'het'
gebruikt, al denk ik dat het ook vanwege 'het koekje' in de toekomst wel
gangbaarder gaat worden.
De wiki-regel lijkt me overigens niet van toepassing aangezien het een Engelse
term is, waardoor het zowiezo 'de' wordt, tenzij er een goed vervangbaar
Nederlands woord voor is en dat kunnen we van 'koekie' niet zeggen.

>En of 'die u wilt toestemming geven' kan beter (omdraaien) waar is, dat is
grotendeels afhankelijk van de streek van herkomst..

Tja, dit is denk ik niet het eerste BE/NL-voorval en het lijkt me toch beter om
deze vertaling zoals gezegd (100%) aan het ABN te laten voldoen. Misschien dus
ook toch iets voor een aparte belgische vertaling, net als enkele andere zaken?

'Informatie' zonder 'de': aangezien 'de' in de oorspronkelijke tekst niet
voorkomt omdat informatie hier een onbepaalde term is en het dus om algemeen
Firefox-gedrag gaat lijkt het me geen bezwaar, dan wel een goede reden om het
inderdaad weg te halen.



    
    

    
  
Dat overzicht van regels op Wikipedia waar ik naar verwees ging specifiek over
leenwoorden ("2b. woorden met de uitheemse achtervoegsels of elementen"), dus
dat gaat wel degelijk op :).

Wat privéinformatie of privé-informatie betreft, of het nou goed is of fout, ik
denk dat er geen haan naar kraait als we het met een streepje schrijven, en als
dat de duidelijkheid ten goede komt (wat denk ik de belangrijkste gedachte
achter - in de Nederlandse taal is) dan zie ik er geen bezwaar tegen :). Echter,
nog even ter referentie:
http://nl.wikipedia.org/wiki/Nederlandse_spelling_%28liggend_streepje%29 en het
Groene boekje zouden duidelijkheid moeten verschaffen.

m.b.t. Vlaamse vertaling: het idee is best aardig imho, maar er zijn twee
potentiële problemen mee: 1. vrijwilligers om het te onderhouden, en 2. hoe ga
je ervoor zorgen dat het synchroon loopt met de Nederlandse vertaling en dat je
geen dubbel werk gaat doen.


~Grauw

    
    

    
  
(In reply to comment #73)
> Dat overzicht van regels op Wikipedia waar ik naar verwees ging specifiek over
> leenwoorden ("2b. woorden met de uitheemse achtervoegsels of elementen"), dus
> dat gaat wel degelijk op :).
> 

De regel is van toepassing op woorden die een uitheemse oorsprong, maar ook
reeds een vertaalde vorm hebben. 'Cookie' is een overgenomen term en bovendien
ook nog een verkleinwoord.. ;)

> Wat privéinformatie of privé-informatie betreft, of het nou goed is of fout, ik
> denk dat er geen haan naar kraait als we het met een streepje schrijven, en als

Zie privé-detective.

> 
> m.b.t. Vlaamse vertaling: het idee is best aardig imho, maar er zijn twee
> potentiële problemen mee:

Ik dacht dat er allang een NL-Be-vertaling bestond. Zoniet, dan pleit ik er
sterk voor. Als er al wel een Friese is.. ;)


    
    

    
  
(In reply to comment #74)
> (In reply to comment #73)
> > Dat overzicht van regels op Wikipedia waar ik naar verwees ging specifiek over
> > leenwoorden ("2b. woorden met de uitheemse achtervoegsels of elementen"), dus
> > dat gaat wel degelijk op :).
> > 
> 
> De regel is van toepassing op woorden die een uitheemse oorsprong, maar ook
> reeds een vertaalde vorm hebben. 'Cookie' is een overgenomen term en bovendien
> ook nog een verkleinwoord.. ;)

Wat er net voor moet pleiten om 'het cookie' te schrijven, daar alle
verkleinwoorden onzijdige woorden zijn.

> > Wat privéinformatie of privé-informatie betreft, of het nou goed is of fout, ik
> > denk dat er geen haan naar kraait als we het met een streepje schrijven, en als
> 
> Zie privé-detective.

Ok, hier geef ik toe: ik had enkel in de digitale GVD gekeken (makkelijker ;-)),
en die schrijft alle privé-samenstellingen aan elkaar, terwijl het GB die net
allemaal met een streepje schrijft, terug met een streepje dus.
 
> > m.b.t. Vlaamse vertaling: het idee is best aardig imho, maar er zijn twee
> > potentiële problemen mee:
> 
> Ik dacht dat er allang een NL-Be-vertaling bestond. Zoniet, dan pleit ik er
> sterk voor. Als er al wel een Friese is.. ;)

Tsja, ik wil hier wel een rol in spelen, maar de tijd die ik eraan kan spenderen
varieert zeer sterk: bu redelijk veel (examens :-p), soms weken geen.

Maar daar ga je toch in de fout: Fries is een heel andere taal.  Er zijn wel
aanzienlijke verschillen tussen Vlaams en Nederlands, maar het blijft nog
dezelfde taal.  Ik stoor me er eigenlijk niet zo aan als ik al eens een
lichtelijk Hollands aandoende term tegenkom in FF (en ja, ik weet dat Nederland
uit meer dan Holland bestaat)


    
    

    
  
(In reply to comment #75)
> > De regel is van toepassing op woorden die een uitheemse oorsprong, maar ook
> > reeds een vertaalde vorm hebben. 'Cookie' is een overgenomen term en
> > bovendien ook nog een verkleinwoord.. ;)
> 
> Wat er net voor moet pleiten om 'het cookie' te schrijven, daar alle
> verkleinwoorden onzijdige woorden zijn.

Alleen wanneer het een Nederlands verkleinwoord betreft natuurlijk, waarbij de
uitgang -je is. Het koekje, de cookie. Engels heeft überhaupt niet echt
‘verkleinwoorden’ zoals wij ze kennen. Affijn, zelfs als je het daar niet mee
eens bent, laten we hier niet verder over discussiëren en gewoon de vorm nemen
waar mensen het minst raar van op zullen kijken. Laten zoals het was dus.

~Grauw

    
    

    
  
(In reply to comment #72)
> > Ok, maar dan moet het privéinformatie zijn, en dat ziet er zo lelijk uit.
> 
> Woorden met 'privé' krijgen wel degelijk een streepje na de é, ondanks de
> verwachting dat er toch geen klinkerbotsing optreedt.
> 
> > Googlefight leert me dat types met s gangbaarder is.  Waarom zou ik het dan
> niet veranderen?  Of is dat zo veel extra werk dan?
> 
> Gebruik nooit Google om te bepalen of iets grammaticaal juist is, zou ik zeggen.

Nee tuurlijk niet, maar ik dacht: als ze allebei kunnen, waarom dan niet de
gangbaarste nemen...

> 'Typen' is min of meer gekozen omdat ook 'lettertypen' wordt gebruikt en
> consistentie is zeker aan te raden. 'Types' wordt dacht ik ook meer gebruikt bij
> personen, of doet er i.i.g. aan denken, maar dat terzijde. ;)

Ja, point taken.

> >Ja, lijkt me ook beter, evt. "slechts eenmaal", dat is de intentie die ik wou
> uitdrukken.
> 
> Pas dan wel op dat je 'but you must enter it once per session' niet verwart met
> 'you must enter it only once per session', dat was de mijne. ;) M.a.w. de nadruk
> op die éénmaal is in de oorspronkelijke tekst niet zo groot; er wordt slechts
> aangegeven dat het paswoord een algemene bescherming geeft, maar dat het wel een
> keer ingevoerd moet worden.

Ah, vinger op de wonde: ik heb de Engelse tekst niet, ik kijk alleen naar zinnen
die me ongrammaticaal voorkomen, en pas die aan.  Waar kan ik de Engelse tekst
vinden?  Ik ben heel erg nieuw met cvs, dus graag uitgebreide aanwijzingen. Met
http://www.mozilla.org/projects/firefox/l10n/using-cvs.html ben ik niet verder
geraakt.

> Cookie: Apple, MS en de Linux-wereld etc. gebruiken ook 'de' en ik vrees toch

Ik blijf erbij dat cookie een verkleinwoord is en dus het moet krijgen.  Het
staat niet in het GB, dus waarom dan niet zoals in het Groot Dictee de tweede
autoriteit op dat gebied, de GVD volgen?

> >En of 'die u wilt toestemming geven' kan beter (omdraaien) waar is, dat is
> grotendeels afhankelijk van de streek van herkomst..
> 
> Tja, dit is denk ik niet het eerste BE/NL-voorval en het lijkt me toch beter om
> deze vertaling zoals gezegd (100%) aan het ABN te laten voldoen. Misschien dus
> ook toch iets voor een aparte belgische vertaling, net als enkele andere zaken?

Het is niet omdat het in Nederland niet de gewoonte is, dat het geen AN is.  Ik
heb geen naslagwerken bij de hand, maar ik betwijfal of het bovenstaande fout
gerekend wordt.

> 'Informatie' zonder 'de': aangezien 'de' in de oorspronkelijke tekst niet

Idd.

    
    

    
  
(In reply to comment #77)
> Ik blijf erbij dat cookie een verkleinwoord is en dus het moet krijgen.  Het
> staat niet in het GB, dus waarom dan niet zoals in het Groot Dictee de tweede
> autoriteit op dat gebied, de GVD volgen?

Dat mag wellicht de regel zijn voor Nederlandse woorden, maar we hebben het hier
over een leenwoord, en daar gelden volledig andere regels voor. En zoals ik al
zei, het concept verkleinwoord bestaat nauwelijks in het Engels, dus een Engelse
woorden als zijnde een verkleinwoord beschouwen en dat meenemen naar een
Nederlandse vertaling is op zijn minst twijfelachtig. 

Gezien het grote aantal fouten in de GVD (sic), vind ik dat geen overtuigend
alternatief voor het groene boekje. De spellingsregels zijn in dat geval
afdoende, en waar er nog onduidelijkheid is kan je het beste gevoelsmatig de
beste oplossing kiezen.

Ten slotte, ik vind dit veels te veel een theoretische discussie. Dan kunnen we
beter ook weer ‘webstek’ in plaats van website invoeren. DE cookie is gangbaar,
en klinkt het best, dus dat gebruiken we. Wij zijn hier niet om het Nederlandse
taalgebruik te verbeteren.


~Grauw

p.s. saillant detail: de etymologie van het Engelse woord ‘cookie’ komt uit het
Nederlands :). m-w.com: "Etymology: Dutch: koekje, diminutive of koek (cake)".
Net zoals het woord ‘snack’ trouwens, maar daarvan bestaat het oorspronkelijke
Nederlandse woord niet eens meer :).

    
    

    
  


  
Ok, hier de herwerkte versie van mijn tweede patch.
- die u toestemming wilt geven
- `de' weg bij informatie
- Bladergeschiedenis -> navigatiegeschiedenis
- gedefinieerd zonder trema

De andere dingen zo gelaten, dat wil dus zeggen privé-informatie, de cookie,
...
Hoop dat nu iedereen hiermee kan leven.
PS: Notepad2 is super, bedankt voor de tip!

    
    

    
  
(In reply to comment #75)
> Maar daar ga je toch in de fout: Fries is een heel andere taal.  Er zijn wel
> aanzienlijke verschillen tussen Vlaams en Nederlands, maar het blijft nog
> dezelfde taal.

Nou, zo erg 'fout' zit ik niet naar mijn mening. ;) Punt is dat qua gangbaarheid
de noodzaak voor een Vlaamse vertaling mij veel groter lijkt dan die voor een
Friese gezien het aantal gebruikers. En hoewel Fries inderdaad een meer
afwijkende taal is, is Vlaams toch ook niet 100% identiek aan het (hedendaags)
Nederlands, dus is er wellicht genoeg draagkracht voor een aparte vertaling.
Daarbij zijn Nederlanders al gauw erg kritisch als een tekst iets te Duits of te
Belgisch aandoet (no offense) en het zou me niets verbazen als Vlamingen er
precies zo over denken, dus aangezien het een ieder vrij staat om een aparte
vertaling te maken, waarom niet? De Vlaamse zou een kopie van de Nederlandse
kunnen zijn met hier en daar een kleine wijziging, dus veel werk is het
misschien niet eens?

Over je patch: ik zie eerlijk gezegd geen reden om 'toestemming geven' te
introduceren, tenzij dat ook gebeurt in de zin die eraan vooraf gaat. Het gaat
daarin en op enkele andere plaatsen steeds over 'toestaan', dus wat is er mis
met '..welke u wilt toestaan..', behalve dat daarachter misschien voor het
gevoel een deel van de zin lijkt te missen?


    
    

    
  
Sorry dat ik zo’n lastig publiek ben :). Deze patch ziet er prima uit, op één
dingetje na: "die u wilt toestemming geven". Dit is nog steeds de Vlaamse
woordvolgorde die echt zeer vreemd op mij over komt. Verder vind ik de
formulering, in tegenstelling tot Ton, wel beter dan de huidige, dus wat mij
betreft mag die als "die u toestemming wilt geven" doorgevoerd worden.

Wat ik nog mis: had je het niet ook over rasterpunten -> pixels? Want dat mag
best veranderd worden ;p.

En als ik me niet vergis is je vorige patch ook nog niet toegepast vanwege zo’n
unicode ding, zie comment 43...

Met betreffing tot Fries vs. Vlaams - juist omdát Vlaams een vrij
rechtstreekse-kopie-maar-net-niet van het Nederlands zou zijn lijkt het me
lastig. Fries zul je gewoon vanaf scratch moeten maken (nuja, met de NL
vertaling als basis lijkt me). Maar bij Vlaams, omdat je dan geen dubbel werk
wilt verrichten, moet je een goede methode hebben om patches in de Nederlandse
vertaling semi-automatisch na een review ook in de Vlaamse vertaling toe te
passen. Aan de andere kant, ik weet niet hoe recht-toe-recht-aan het Fries zich
verhoudt tot het Nederlands, maar daar zou zoiets wellicht ook van pas kunnen komen.


~Grauw

    
    

    
  


  
Dit is de eerdere patch van Hendrik, alleen dan zonder toevoeging van de
Unicode BOM.

~Grauw

    
    

    
  
(In reply to comment #81)
> Sorry dat ik zo’n lastig publiek ben :). Deze patch ziet er prima uit, op één
> dingetje na: "die u wilt toestemming geven". Dit is nog steeds de Vlaamse..
Ik wil niet vervelend zijn maar zou eerst graag gegronde reden zien om af te
wijken van de oorspronkelijke Engelse tekst (te meer daar is gehandeld zonder
die ernaast te hebben). En áls het gebeurt, dan dus ook voor de rest van de tekst.

> En als ik me niet vergis is je vorige patch ook nog niet toegepast vanwege zo’n
> unicode ding, zie comment 43...
> 

Wijzigingen daaruit waren reeds meegenomen in attachment 185552 [details] [diff] [review].


    
    

    
  
(In reply to comment #83)
> (In reply to comment #81)
> > Sorry dat ik zo’n lastig publiek ben :). Deze patch ziet er prima uit, op één
> > dingetje na: "die u wilt toestemming geven". Dit is nog steeds de Vlaamse..

Dan heb je niet goed gekeken, want ik heb er wel degelijk `die u toestemming
wilt geven' van gemaakt.

> Ik wil niet vervelend zijn maar zou eerst graag gegronde reden zien om af te
> wijken van de oorspronkelijke Engelse tekst (te meer daar is gehandeld zonder
> die ernaast te hebben). En áls het gebeurt, dan dus ook voor de rest van de tekst.

Het gaat niet over het afwijken van de Engelse tekst, dan wel om het
grammaticaal zijn van de zin.  'een website die u wilt toestaan' is nonsens:
over het bestaan van een website heb je niks te zeggen.  Het gaat erom of je die
website (meewerkend voorwerp) wilt toestemming geven om (toestemming wilt geven
om ;-)) al dan niet cookies te plaatsen (of wat dan ook).  Als ik de
oorspronkelijke zin lees, dan wringt dat.

Wat betreft Fries vs. Vlaams heeft Laurens Holst de nagel op de kop: ik zou niet
weten hoe eraan te beginnen, net omdat het maar zo minimale verschillen zijn. 
Zelfs als ik nu aan een Vlaamse versie zou beginnen, dan zou ik `die u
toestemming wilt geven' laten staan, dit is nl. naar mijn gevoel niet on-Vlaams
Nederlands...  Als er ooit iemand aan begint, dan zal ik met graagte meewerken,
maar zelf zal ik er niet aan beginnen.

Wat rasterpunten betreft: ik maak nog een patchje hiervoor, en dan wou ik ook in
het gedeelte over de toestemmingen een consequente lijn trekken in websites dan
wel sites.  Als ik het goed begrepen heb heeft het eerste de voorkeur?

    
    

    
  
Nog eens over toestemming: je geeft de site toestemming, de popup/cookie/... sta
je toe.  In het Engels wordt hier geen onderscheid gemaakt, denk ik, maar in het
Nl lijkt me dat wel nodig.

Kan me verder nog iemand even uitleggen wat die Flags betekenen?

En waarvoor BOM staat?

    
    

    
  
> Dan heb je niet goed gekeken, want ik heb er wel degelijk `die u toestemming
> wilt geven' van gemaakt.

Sorry, je hebt gelijk.


> Het gaat niet over het afwijken van de Engelse tekst, dan wel om het
> grammaticaal zijn van de zin.  'een website die u wilt toestaan' is nonsens:
> over het bestaan van een website heb je niks te zeggen.  Het gaat erom of je
> die website (meewerkend voorwerp) wilt toestemming geven om (toestemming wilt
> geven om ;-)) al dan niet cookies te plaatsen (of wat dan ook).  Als ik de
> oorspronkelijke zin lees, dan wringt dat.

Hier ben ik het helemaal mee eens. Vergelijk:

Org: "You can specify which web sites are allowed to install software. Type the
exact address of the site you want to allow and then click Allow."

1: "U kunt aangeven welke websites het is toegestaan programmatuur te
installeren. Typ het exacte adres van de website die u wilt toestaan en klik
vervolgens op Toestaan."

2: "U kunt aangeven welke websites het is toegestaan programmatuur te
installeren. Typ het exacte adres van de website die u toestemming wilt geven en
klik vervolgens op Toestaan."

De middelste zin is vreemd. Je kan iets niet willen toestaan. Je kan iets wel
willen toestaan programmatuur te installeren. Je kan iets ook toestemming geven
daarvoor. Je kan iets niet willen toestaan daarvoor. Het ‘toestaan’ mist wat.


> Kan me verder nog iemand even uitleggen wat die Flags betekenen?

Die flags zijn voor als de er bijna een release is, dan moet elke patch een
review krijgen voordat hij wordt ingecheckt. Met die flags vraag je zo’n review
aan. Maar dat is nu nog niet van toepassing, waarschijnlijk zodra Firefox 1.1 in
de béta fast komt gaan ze wel gebruikt worden.


> En waarvoor BOM staat?

BOM staat voor Byte Order Mark, ook bekend als Unicode signature. In UTF-8 files
kun je aan die drie bytes herkennen dat het om een UTF-8 file gaat, en in UTF-16
kan je aan de hand van die twee bytes achterhalen of het een little endian of
big endian UTF-16 file is. Een BOM heeft zijn nut, maar is vaak ook vervelend.


Ton schreef:
> Wijzigingen daaruit waren reeds meegenomen in attachment 185552 [details] [diff] [review] [edit].

Dan had Tim daar iets duidelijker over mogen zijn >.<


~Grauw

    
    

    
  
Comment on attachment 186046 [details] [diff] [review]
Zonder BOM (was: enkele schoonheidsfoutjes, en 'sleuren' -> 'slepen')

Obsolete - al reeds toegepast.

        Attachment #186046 -
        Attachment is obsolete: true

    
    

    
  
Aan de opmerkingen over de vertaling heb ik niets meer toe te voegen. Huidige
patch lijkt me goed. Wel over een eventuele Belgische versie. 
Het is denk ik onhoudbaar om zoiets actief bij te houden. Een Belgische
vertaling zou daarom een aangepaste Nederlandse versie moeten zijn na het
verschijnen van een officiële Firefox versie of pas gemaakt worden een paar
weken voordat een nieuwe Firefox versie uitgegeven is. Met de kwaliteit van de
Nederlandse vertaling op dit moment zal er nadat Firefox 1.1 het bètastadium
bereikt heeft niet heel veel meer moeten veranderen. Een probleem wat je echter
blijft houden is dat de Belgische in de trunk bij volgende versies steeds een
brandende tinderbox oplevert. Daar moet nog wat op gevonden worden.

    
    

    
  


  
Enkele koppelstreepjes weggehaald.  Het lijkt misschien vreemd, maar het hoort
nu eenmaal zo.	Niet schieten op de pianist... Over basispaginastijl viel nog
te discussiëren op grond van de leesbaarheidsregel, maar ik vind het zo toch
beter.	Verder weet ik niet of er speciale redenen waren waarom er nog Embed
stond, en lijkt me standaardmodus logischer, of begrijp ik de betekenis daar
verkeerd?

    
    

    
  
Standaardenmodus is correct, ‘standards mode’ in Engels. Het betreft dus modus
van standaarden, en niet standaardmode alsin default mode oid.

Embed moet ook Embed blijven, dat is nl. de naam van een HTML tag. Anders moet
de gebruiker wel héél erg hard nadenken voordat hij doorheeft dat Ingebed op
<embed> slaat, in tegenstelling tot Object --> <object>.

Mediavoorbeeld en Titelloze pagina zijn wel ok.

Deelvensterinfo heb ik mijn twijfels over (met name in verband met consistentie
met pagina-info). Basispaginastijl ben ik het denk ik ook mee oneens, maar ik
zal zodirect mijn nl build eens raadplegen, die als het goed nu klaar is :).


~Grauw

    
    

    
  
(In reply to comment #90)
> Standaardenmodus is correct, ‘standards mode’ in Engels. Het betreft dus modus
> van standaarden, en niet standaardmode alsin default mode oid.
> 
> Embed moet ook Embed blijven, dat is nl. de naam van een HTML tag. Anders moet
> de gebruiker wel héél erg hard nadenken voordat hij doorheeft dat Ingebed op
> <embed> slaat, in tegenstelling tot Object --> <object>.

Dat vreesde ik al.  Ik moet echt een Engelse versie zien te pakken krijgen.  Kan
iemand me daarvoor een pointer geven?
 
> Mediavoorbeeld en Titelloze pagina zijn wel ok.
> 
> Deelvensterinfo heb ik mijn twijfels over (met name in verband met consistentie
> met pagina-info).

Pagina-info moet met een streepje omdat a en i botsende klinkers zijn.  In
deelvensterinfo is hier hoegenaamd geen reden toe.

> Basispaginastijl ben ik het denk ik ook mee oneens, maar ik
> zal zodirect mijn nl build eens raadplegen, die als het goed nu klaar is :).

Tsja, ik krijg dat nergens te zien als ik hier op Pagina-info klik, dus weet ook
niet goed waarop het slaat.  Maar dit lijkt me een samenstelling als
hogesnelheidstrein en basisgezondheidsdienst (GB) en basispolitiezorg (GB).  Aan
elkaar dus.  (Je zal wel al gemerkt hebben dat ik een spellingfreak ben. 
Correctheid vind ik zeer belangrijk, het is ook hetgeen de gebruikers te zien
krijgen en zodoende een uithangbord.)



    
    

    
  
(In reply to comment #91)
> Dat vreesde ik al.  Ik moet echt een Engelse versie zien te pakken krijgen.
> Kan iemand me daarvoor een pointer geven?

Je kan op http://lxr.mozilla.org/mozilla/ naar de bestandsnaam zoeken.


> > Basispaginastijl ben ik het denk ik ook mee oneens, maar ik
> > zal zodirect mijn nl build eens raadplegen, die als het goed nu klaar is :).
> 
> Tsja, ik krijg dat nergens te zien als ik hier op Pagina-info klik, dus weet
> ook niet goed waarop het slaat.  Maar dit lijkt me een samenstelling als
> hogesnelheidstrein en basisgezondheidsdienst (GB) en basispolitiezorg (GB).
> Aan elkaar dus.  (Je zal wel al gemerkt hebben dat ik een spellingfreak ben. 
> Correctheid vind ik zeer belangrijk, het is ook hetgeen de gebruikers te zien
> krijgen en zodoende een uithangbord.)

Jajaja :). Ik vind het ook belangrijk, maar koppelstreepjes zijn wel enigszins
een grijs gebied, waarin ook enige vrijheid wordt gelaten.

In het geval van Basis-paginastijl, dat zou je als het goed is in menu Beeld >
Paginastijl terug moeten vinden.


~Grauw

    
    

    
  
Ik stel voor om Basis-paginastijl als Basisstijl te vertalen. Het woord pagina
zit al in het menu waar dat in staat, dus dat is duidelijk genoeg.

    
    

    
  
(In reply to comment #93)
> Ik stel voor om Basis-paginastijl als Basisstijl te vertalen. Het woord pagina
> zit al in het menu waar dat in staat, dus dat is duidelijk genoeg.

Wat mij betreft klopt de uitleg over 'toestaan' wel aardig; het is de precieze
reden dat ik eerder sprak over het missende deel van de zin. Toch bestaat er wat
wringen betreft naar mijn mening hetzelfde probleem van een missend meewerkend
voorwerp met 'toestemming geven', al valt het wel iets minder op. De vraag is
immers in beide gevallen 'voor wat?' In de zin ervoor wordt de bijbehorende
actie goed beschreven en juist daarom is het weglaten van dat missende deel nou
niet zo erg in deze zin, maar dit geldt dan voor allebei. Onmogelijk is het
bovendien niet om iets toe te staan ("Staat u mij toe?"), misschien wel wat
ouderwets. Hoe dan ook, 'toestemming geven' klinkt over het algemeen wel beter
dus als je de andere strings ook ombouwt vind ik het goed (zoals 'welke websites
toestemming hebben om ..').

Misschien is dit wel een van de redenen dat het handig is om bij het
grammaticaal nalopen van een tekst een originele ernaast te houden, maar ook om
de tekst in het uiteindelijke scherm te zien zodat bepaalde zaken dan pas gaan
opvallen? ;)

>Dan had Tim daar iets duidelijker over mogen zijn >.<

Schreef Gert-Paul het niet in comment #46?

Over de nieuwe (streepjes)zaken:
De meeste overgebleven streepjes zijn (als het goed is) alleen ter
verduidelijking neergezet of erin gelaten en 'Deelvensterinfo' kan wel.
Standaardenmodus is als ik me niet vergis correct (komt toch van 'standards
mode', een standaardmodus is iets anders), Ingebed zou ik zeker niet doen omdat
het een van de vele kreten is die net als die erboven in de patch bewust engels
blijven in dagelijks gebruik en 'Basis-paginastijl' houdt omwille van
leesbaarheid én betekenis toch mijn voorkeur. Het gaat hier om een basisvorm
voor een paginastijl en niet om de stijl van een basispagina, zelfs al zou de
betekenis ervan (toevallig) precies hetzelfde zijn. Laurens' voorstel hierboven
is echter ook geen gek idee. Mediavoorbeeld had ik inderdaad nog gevonden.
Grappige bijkomstigheid daarbij is de betekenis in Google. ;)

    
    

    
  
(In reply to comment #94)
Sorry, 'grappige' hierboven was niet het juiste woord, moest 'vage' o.i.d. zijn.
Verder nog iets over lijdend i.p.v. meewerkend voorwerp maar dat is denk ik wel
duidelijk. Het is laat. ;)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Reporter patch (obsolete)
        — 
          — Splinter Review
      

    


  
Reporter nagekeken op fouten.

Noemenswaardige veranderingen:
- Kapotte -> defecte.
- Versturen -> verzenden (consistentie).

~Grauw

    
    

    
  
Ja, maar toen ik er naar vroeg werd ik op comment 43 gewezen :).

Ik heb dus vanaf vandaag weer een (eigengebouwde) Nederlandse build. Yay :). Ik
houd bij vertalingen ook altijd zowel de browser zelf als de Engelse bron bij de
hand.

Zou wel handig zijn als dat vergelijken tussen Engels en Nederlands automatisch
kon, maar Mozilla Translator is zo ononderhouden en heeft dermate veel kuren dat
niemand dat meer aan durft geloof ik ^_^. Desalniettemin, een vergelijkbaar
tooltje zou handig zijn. Wellicht is dat een leuk projectje om even snel in C#
in elkaar te klussen :).


~Grauw

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Livebookmarks (obsolete)
        — 
          — Splinter Review
      

    


  
Kleinigheidjes, maar bijvoorbeeld ook 'livebookmarks' (à la 'liveuitzending')
en 'Help-inhoud'..

    
    

    
  
Ik ben voor Basistijl, pagina staat inderdaad al in het verwijzende menu.

Wat het toestaan betreft: we convergeren naar een standpunt, goed zo (de
wiskundige in mij komt even boven :-)
Dan zou `Toegestane sites' ook moeten veranderen.  Ik dacht aan geprivilegieerde
websites, maar dat klinkt zo moeilijk, iemand betere suggesties?  Websites met
toestemming?


    
    

    
  
Livebladwijzers aan elkaar ben ik het niet mee eens.

- "Op nieuwe versies controleren..." --> "Op updates controleren..."
Waarom dat? Update wordt toch niet overal update genoemd (ook bijwerken e.d.)
dus ik zie niet waarom wij hier updates willen gebruiken, dan liever Nederlands.

- restartBeforeDisableTitle=Extensie deactiveren
In de extension manager is er sprake van inschakelen en uitschakelen, niet
activeren en deactiveren.


~Grauw

    
    

    
  
Mijn suggestie: noem het Uitzonderingen, net zoals het scherm van cookies.
Alternatief: websites met permissie?

Het menu van de popupblokkeringsbalk zegt ook "opties voor popupblokkering
bewerken", hierbij zie ik graag de aanpassing ‘bewerken’ --> ‘aanpassen’.

~Grauw

    
    

    
  
(In reply to comment #98)
> Created an attachment (id=186054) [edit]
> Livebookmarks
> 
> Kleinigheidjes, maar bijvoorbeeld ook 'livebookmarks' (à la 'liveuitzending')
> en 'Help-inhoud'..

Daar gaan we weer: Help-inhoud??  Wat is dat voor monster?  Ik kan nog inzien
waarom je dat met hoofdletter zou schrijven, maar een streepje is echt helemaal
uit den boze.

En je bedoelt livebladwijzers, maar dat is ok in de patch, zie ik.

Over Notificatie i.p.v. waarschuwen ben ik ook niet zo enthousiast.  Dat klinkt
nogal opgefokt, als je het mij vraagt.  En 'de notificatie aanpassen', wat
betekent dat?  Dan is 'het waarschuwingsschema aanpassen' toch duidelijker.

Navigeren vervangen door Bladeren, dat kan je toch niet menen?  Dat was nu toch
definitief Navigeren geworden?

Wat is er mis met uitschakelen, waarom het onding deactiveren? (ok, er staat
activeren, maak daar dan inschakelen van, als je wil dat ze samen passen.)

Licentieovereenkomst: inderdaad.

Bijwerken i.p.v. updaten: nu ja.

    
    

    
  
(In reply to comment #102)
> Navigeren vervangen door Bladeren, dat kan je toch niet menen?  Dat was nu toch
> definitief Navigeren geworden?

Het gaat hier om bladeren naar een bestand, en daar is de term wel bladeren voor.

m.b.t. Help-inhoud ben ik het eens, in het menu heet het Helpinhoud, maar
hoofdlettergebruik daarvoor in de tekst is natuurlijk onzin.

m.b.t. bijwerken ipv updaten: prima.


~Grauw

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Fix installer & build error (obsolete)
        — 
          — Splinter Review
      

    


  
Deze patch zou als het goed is een installer build probleem moeten verhelpen
(en de tinderbox weer groen moeten maken).

    
    

    
  
(In reply to comment #100)
:)

>Dan zou `Toegestane sites' ook moeten veranderen.
Misschien zou dit nog wel kunnen, of je laatste oplossing. De middelste wordt
wat lastig leesbaar, zeker als je nergens 'privileges' hanteert. (= Vlaams? ;))

> 
Livebladwijzers aan elkaar ben ik het niet mee eens.
> 
Ik ook niet en nam tot voor kort aan dat 'live' een bijvoeglijk naamwoord is,
maar de regel zegt anders. Kun je die misschien goed weerleggen? :)

> - "Op nieuwe versies controleren..." --> "Op updates controleren..."
> Waarom dat? Update wordt toch niet overal update genoemd (ook bijwerken e.d.)
> dus ik zie niet waarom wij hier updates willen gebruiken, dan liever Nederlands.

Hmja.. m.a.w. consistentie niet overal toepassen? N.a.v. comment #34 en respons
(ww=bijwerken, znw=update) dacht ik dat dat misschien nog de bedoeling was met
'updates', en dat 'nieuwe versies' er in zijn geheel wel uit kon. Ik vind het
vaak wat oubollig/overbodig klinken, zeker als het overal wordt toegepast maar
een enkele keer kan het geen kwaad. Wel uit het menu halen?
> 
> - restartBeforeDisableTitle=Extensie deactiveren
> In de extension manager is er sprake van inschakelen en uitschakelen, niet
> activeren en deactiveren.

Dan hier allebei ook maar. Ik stond in consistentiemodus. ;)


    
    

    
  

      
      
      
      

        Attached patch
          
          
        Install.it file review (obsolete)
        — 
          — Splinter Review
      

    


  
Ik heb de install.it file gereviewd, en deze wijzigingen aangebracht.

    
    

    
  


  
Wat correcties van conflicterende menusneltoetsen, hun aangepaste waardes
volgen de menu’s in IE.

Ook wat inconsistenties met de Engelse tekst gecorrigeerd.

Dat is het voor vanavond. Ik beloof de volgende keer wat grotere patches te
maken :).

~Grauw

    
    

    
  
(In reply to comment #104)
> Created an attachment (id=186056) [edit]
> Fix installer & build error
> 
> Deze patch zou als het goed is een installer build probleem moeten verhelpen
> (en de tinderbox weer groen moeten maken).

En weer gelokaliseerde Windows builds beschikbaar moeten maken.

Snel toepassen dus! Dan hoef ik niet meer zelf te builden :).

De daadwerkelijke inhoud van installer.inc heb ik nog niet uitgebreid naar
gekeken, maar ik zag wel dat er flink wat inconsistenties waren met de Engelse
tekst, de algemene indruk was dat er in het Engels meer staat. Ik weet niet of
dat het Nederlands intentioneel korter is gehouden of dat dat komt omdat dit nog
een oude vertaling is. Kan iemand mij enige verlichting over geven? :)


~Grauw

    
    

    
  
(In reply to comment #105)
> :)
> 
> >Dan zou `Toegestane sites' ook moeten veranderen.
> Misschien zou dit nog wel kunnen, of je laatste oplossing. De middelste wordt
> wat lastig leesbaar, zeker als je nergens 'privileges' hanteert. (= Vlaams?;))

Privileges is in principe gewoon Nederlands hoor, hetzij wat formeel :) (maar
dat is wel vaker zo met in Vlaanderen veel gebruikte woorden).

> > Livebladwijzers aan elkaar ben ik het niet mee eens.
> 
> Ik ook niet en nam tot voor kort aan dat 'live' een bijvoeglijk naamwoord is,
> maar de regel zegt anders. Kun je die misschien goed weerleggen? :)

Ik zou zeggen, feitelijk vertalen we alleen het woord ‘bookmarks’ uit Live
Bookmarks en laten we het ‘live’ ongemoeid, dus moeten we ook in het Nederlands
die spatie lekker laten zitten.

Livebladwijzers ziet er gewoon vrij verschrikkelijk uit, dus ik moet hier een
beter argument dan taalpurisme voor zien wil ik overtuigd raken.


> > - "Op nieuwe versies controleren..." --> "Op updates controleren..."
> > Waarom dat? Update wordt toch niet overal update genoemd (ook bijwerken
> > e.d.) dus ik zie niet waarom wij hier updates willen gebruiken, dan liever
> > Nederlands.
> 
> Hmja.. m.a.w. consistentie niet overal toepassen? N.a.v. comment #34 en respons
> (ww=bijwerken, znw=update) dacht ik dat dat misschien nog de bedoeling was met
> 'updates', en dat 'nieuwe versies' er in zijn geheel wel uit kon. Ik vind het
> vaak wat oubollig/overbodig klinken, zeker als het overal wordt toegepast maar
> een enkele keer kan het geen kwaad. Wel uit het menu halen?

Het is vrij simpel, we gebruiken in principe bijwerken maar dat woord is niet
overal van toepassing, of het klinkt raar. Idem voor ‘nieuwe versie’ vs. update.
Dus in die gevallen gebruiken we update. En waar er ‘locale inconsistenties’
optreden (bijv. in de tekst bijwerken maar op de knop update omdat dat moeilijk
anders kan) kiezen we dan voor consistentie. ‘Globale consistentie’ hoeft in dit
geval niet zo nodig, omdat dat moeilijk is tenzij we overal update gaan gebruiken.


> > - restartBeforeDisableTitle=Extensie deactiveren
> > In de extension manager is er sprake van inschakelen en uitschakelen, niet
> > activeren en deactiveren.
> 
> Dan hier allebei ook maar. Ik stond in consistentiemodus. ;)

:)


~Grauw

    
    

    
  
(In reply to comment #102)
> Daar gaan we weer: Help-inhoud??  Wat is dat voor monster?

Ik ben er ook niet gek op, geloof me :) maar inhoud is toch een subonderdeel van
het Help-onderdeel (?), dus wordt het al gauw een geval als een 'Fiat-uitlaat'.
Vergeleken met 'motorinhoud' klopt het wel, maar de hoofdletter voor het
onderdeel lijkt inderdaad niet overbodig en als het vervolgens als een
eigennaam-samenstelling gezien mag/moet worden ontkom je er niet aan, zo
redeneer ik. Kun jij anders verklaren waarom MS de in comment #41 genoemde
termen hanteert en (laat ik het toch ook maar eens noemen ;)) er pakweg een
paarhonderd Google-resultaten voor 'help-inhoud' te vinden zijn, i.t.t. die 16
voor helpinhoud? (Ik had hierop boven overigens nog weinig respons gezien dus
deed hem er daarom bij.)

> 
> En je bedoelt livebladwijzers, maar dat is ok in de patch, zie ik.
>
?
 
> Over Notificatie i.p.v. waarschuwen ben ik ook niet zo enthousiast.  Dat klinkt
> nogal opgefokt, als je het mij vraagt.  En 'de notificatie aanpassen', wat
> betekent dat?  Dan is 'het waarschuwingsschema aanpassen' toch duidelijker.

Niks ergs aan notificatie als je het mij vraagt (Engels: notification).
Waarschuwen vind ik erger, anders liever nog 'aankondiging', of 'het
waarschuwen'. Niks met schema; als je de functie kent (niet alle Firefox-versies
hebben hem) zul je weten dat het over een aantal opties gaat voor het instellen
van bekendmaking, dus de manier waarop. Dit heeft dus niets te maken met het
eerder besproken tijdschema voor het bijwerken van de bookmarks. Zie
http://www.testingeducation.org/k04/examples/dom03s.html.

Overigens kun je engelse teksten ook vinden in en-US.jar in de Firefox-programmamap.

> 
> Bijwerken i.p.v. updaten: nu ja.

Dus jij pleit ook voor soms wel/niet?

    
    

    
  
Even ter verduidelijking: in de build die ik hier heb die vrij vers uit CVS komt
staat er ‘Helpinhoud’, en geen ‘Help-inhoud’. Van mij hoeft dat streepje ook
niet, het ziet er prima uit zo.

En als je toch Google gebruikt om op "Help-inhoud" te zoeken, tel dan ook meteen
het aantal voorkomens van "Help inhoud" zonder streepje :).

Notificatie lijkt mij op zich prima, maar dat geldt ook voor het huidige
‘waarschuwing’. Ik vraag me überhaupt af waar ik dit in Firefox kan vinden,
zodat ik het in zijn context kan bekijken. Zolang ik dat niet heb gezien gaat
mijn voorkeur er naar uit om het te houden zoals het was.


~Grauw

    
    

    
  
(In reply to comment #111)
>Privileges is in principe gewoon Nederlands hoor, hetzij wat formeel :) (maar
>dat is wel vaker zo met in Vlaanderen veel gebruikte woorden).

Inderdaad, ik doelde op 'geprivilegieerde'. :)

Uit nieuwsgierigheid: 'Verkennen' voor lokaal 'Bladeren' is neem ik aan uit den
boze?

>En als je toch Google gebruikt om op "Help-inhoud" te zoeken, tel dan ook
>meteen het aantal voorkomens van "Help inhoud" zonder streepje :).

Had ik gedaan, ik schatte 286-86. ;)

> 
> Notificatie lijkt mij op zich prima, maar dat geldt ook voor het huidige
> ‘waarschuwing’. Ik vraag me überhaupt af waar ik dit in Firefox kan vinden,
> zodat ik het in zijn context kan bekijken. Zolang ik dat niet heb gezien gaat
> mijn voorkeur er naar uit om het te houden zoals het was.
> 

Bekendmaking zou ook nog kunnen. Van waarschuwingen word ik bang. :)
Het schijnt een feature te zijn die al bij 1.0 onklaar is gemaakt en als ik me
niet vergis weg zal blijven, ook door de ontwikkeling van RSS. Desalniettemin
lijkt me niks mis met het plaatsen van correcte tekst (mocht ie terugkomen..) of
voor mensen met eigen builds, waarbij de feature misschien wel werkt. Dat
'schema' was er de afgelopen week ingeslopen, het was eerder 'het waarschuwen'.

Zag nog een paar kleinigheidjes (gedownloadde, .de. Windows Taakbeheer, ...naar
(punt_spatie?))..


    
    

    
  
Comment on attachment 186037 [details] [diff] [review]
vernieuwde versie van browser.patch

Patch is toegepast

        Attachment #186037 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186050 [details] [diff] [review]
enkele liggende streepjes verwijderd, andere kleinigheden

Niet toegepast, graag een nieuwe met comment #90 verwerkt

        Attachment #186050 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186053 [details] [diff] [review]
Reporter patch

patch toegepast

        Attachment #186053 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186054 [details] [diff] [review]
Livebookmarks

Niet toegepast, graag een nieuwe patch met de opmerkingen vanaf comment #100
verwerkt

        Attachment #186054 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186056 [details] [diff] [review]
Fix installer & build error

Patch toegepast. Alleen zal dit nog niet in een groene tinderbox resulteren,
helaas. Dat probleem zit nog in de "build"machines van MozO.

p.s. graag je patches de extensie .patch meegeven, dat je de patch noemt naar
wat het voornamelijk patched is erg fijn.

        Attachment #186056 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #108)
> (In reply to comment #104)
> > Created an attachment (id=186056) [edit] [edit]
> > Fix installer & build error
> > 
> > Deze patch zou als het goed is een installer build probleem moeten verhelpen
> > (en de tinderbox weer groen moeten maken).
> 
> En weer gelokaliseerde Windows builds beschikbaar moeten maken.
> 
> Snel toepassen dus! Dan hoef ik niet meer zelf te builden :).
> 
> De daadwerkelijke inhoud van installer.inc heb ik nog niet uitgebreid naar
> gekeken, maar ik zag wel dat er flink wat inconsistenties waren met de Engelse
> tekst, de algemene indruk was dat er in het Engels meer staat. Ik weet niet of
> dat het Nederlands intentioneel korter is gehouden of dat dat komt omdat dit nog
> een oude vertaling is. Kan iemand mij enige verlichting over geven? :)
> 
> 
> ~Grauw


Waarschijnlijk (ik heb niet gekeken) een oude vertaling. De vergelijkingsscrips
die ik gebruik om de engelse en de nederlandse te synchroniseren kunnnen dat
bestand niet vergelijken (en ik heb er eerlijk gezegt ook niet met de hand meer
naar gekeken).

    
    

    
  
Comment on attachment 186059 [details] [diff] [review]
Install.it file review

Patch toegepast

        Attachment #186059 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186061 [details] [diff] [review]
Correcties in browser.dtd, pageInfo.dtd

Patch toegepast.

Bedankt allemaal voor de vele patches en goede discussie. Vergeet niet je
lokale CVS bestanden bij te werken.

        Attachment #186061 -
        Attachment is obsolete: true

    
    

    
  


  
Ok, herwerkte versie.

- Standaardenmodus laten staan (hoewel het in het Eng nu Standards compliance
mode is, kunnen we die compliance er niet nog in krijgen?  Idem Embed
- Mediavoorbeeld
- deelvensterinfo
- Titelloze pagina

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Livebladwijzers, aangepast (obsolete)
        — 
          — Splinter Review
      

    


  
De livebladwijzers-patch, waarin 'livebladwijzers' en 'help-inhoud' zijn
verwijderd. Ik zou nog wel graag wat respons zien over de juistheid en het
gebruik van deze twee termen.

In comment #104 genoemde nieuwe kleinigheidjes uit install.it meegenomen.
Hierin staat overigens nog wel een paar maal 'creëren'. Was het misschien de
bedoeling die ook te verwijderen?

Verder zie ik een V verschijnen voor reloadCmd.accesskey in browser.dtd. Kan
dat niet beter (ook globaal indien mogelijk) de n worden?

Dan nog even n.a.v. 'update': ik heb gemerkt dat 'nieuwe versie' voor zowel
'update' als 'upgrade' wordt gebruikt, terwijl ik eerder had begrepen dat het
alleen een vertaling van 'upgrade' was en 'update' alleen stond voor
'bijwerking'. Mogen we aannemen dat dit 'geaccepteerd gesmokkel' is? :)

    
    

    
  
(In reply to comment #117)
> (From update of attachment 186056 [details] [diff] [review] [edit])
> Patch toegepast. Alleen zal dit nog niet in een groene tinderbox resulteren,
> helaas. Dat probleem zit nog in de "build"machines van MozO.

Oh, helaas. Ik zag in de lijst van builds dat Arabisch wel werkte, dus er moet
toch íets goed gaan... Maar je hebt gelijk, veel haalt het niet uit :). Nuja,
lokaal build de installer nu iig wel. Als iemand nog graag een build wil, roept
u maar.


> p.s. graag je patches de extensie .patch meegeven, dat je de patch noemt naar
> wat het voornamelijk patched is erg fijn.

Hij heet install.inc.patch... :)


(In reply to comment #118)
> Waarschijnlijk (ik heb niet gekeken) een oude vertaling. De
> vergelijkingsscrips die ik gebruik om de engelse en de nederlandse te
> synchroniseren kunnnen dat bestand niet vergelijken (en ik heb er eerlijk
> gezegt ook niet met de hand meer naar gekeken).

Ok, dan weet ik dat ik daar als ik er zin in heb nog naar kan kijken :).


(In reply to comment #121)
> hoewel het in het Eng nu Standards compliance
> mode is, kunnen we die compliance er niet nog in krijgen?

Denk dat dat lastig wordt. Maakt niet zoveel uit, het is zo ook wel duidelijk.


(In reply to comment #122)
> In comment #104 genoemde nieuwe kleinigheidjes uit install.it meegenomen.

Deze is al reeds toegepast.


> Hierin staat overigens nog wel een paar maal 'creëren'. Was het misschien de
> bedoeling die ook te verwijderen?

"Kon dialoogvenster %s niet creëren." heb ik expres zo gelaten. "Kon de map %s
niet creëeren. (...)" moet inderdaad ook ‘aanmaken’ zijn.


~Grauw

    
    

    
  
> >Privileges is in principe gewoon Nederlands hoor, hetzij wat formeel :) (maar
> >dat is wel vaker zo met in Vlaanderen veel gebruikte woorden).
> 
> Inderdaad, ik doelde op 'geprivilegieerde'. :)

Zelfs dat is nog wel acceptabel Nederlands, alhoewel het in de volksmond niet zo
snel gebruikt zal worden :).

> Uit nieuwsgierigheid: 'Verkennen' voor lokaal 'Bladeren' is neem ik aan uit
> den boze?

Ja, Bladeren is de term die daar door heel Windows heen voor gebruikt wordt.


~Grauw

    
    

    
  
(In reply to comment #123)
> > In comment #104 genoemde nieuwe kleinigheidjes uit install.it meegenomen.
> 
> Deze is al reeds toegepast.

Dat was wel duidelijk. Ik bedoelde dan ook comment #112.

> "Kon de map %s niet creëeren. (...)" moet inderdaad ook ‘aanmaken’ zijn.

Even onthouden.

> Zelfs dat is nog wel acceptabel Nederlands, alhoewel het in de volksmond niet
> zo snel gebruikt zal worden :).

My point exactly. :)


    
    

    
  
Comment on attachment 186076 [details] [diff] [review]
aangepaste versie van liggende streepjes

patch toegepast

        Attachment #186076 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186091 [details] [diff] [review]
Livebladwijzers, aangepast

patch toegepast

        Attachment #186091 -
        Attachment is obsolete: true

    
    

    
  
Hoe werkt dat met de snapshots onder browser/help/images?  Hoe worden die
geüpdate als er teksten die erop afgebeeld staan veranderen?  
Ik heb de indruk dat het bestand urlbar.png niet helemaal klopt, de g staat er
maar half op.

    
    

    
  
(In reply to comment #128)
> Hoe werkt dat met de snapshots onder browser/help/images?  Hoe worden die
> geüpdate als er teksten die erop afgebeeld staan veranderen?  
> Ik heb de indruk dat het bestand urlbar.png niet helemaal klopt, de g staat er
> maar half op.

De hele help moet nog nagekeken worden op veranderingen sinds versie 1, zie
hiervoor bug 293223.

in deze bug moeten volgens mij ook een alle afbeeldingen doorgenomen worden.



    
    

    
  


  
Ik heb het bestand cookies.xhtml eens herwerkt.  Het is nog lang niet ideaal,
maar nu tenminste consistent met 1.0.4 (ik heb geen nightly om te zien wat er
veranderd is ondertussen, dat laat ik aan de profi's over).

Let op: ik heb `dat cookie' in `die cookie' veranderd!	Braaf hé!

Het beste lijkt me om het resultaat van het geheel te zien, daarom zal ik de
herwerkte xhtml ook nog attachen.

    
    

    
  


  
Dit is dus het nieuwe helpbestand.

Ik weet niet of het zinvol is om zulke dingen te doen, zo nee, laat me dat
weten, zo ja, dan ga ik de rest van het lijstje af...

Of hoort dit in een andere bug?

    
    

    
  
(In reply to comment #131)
Cookies.xhtml ziet er wel aardig uit. Kleinigheidjes: misschien is het een idee
om achter 'terwijl u op die website bent' een komma te plaatsen en eventueel die
eerder in die zin te verwijderen? 'Zich .. bevindt' lijkt me hier ook wat beter
dan 'bent' en wat komma's betreft zouden er in deze tekst wel meer weg kunnen
(wellicht zijn er wat blijven hangen uit het Engels). Ook zag ik 'dan deze die u
bezoekt'. Dat kan ook beter, bijv. door 'dan degene die u bezoekt' of 'dan die
welke u bezoekt'. En vooral niet te vergeten 'de volgende keer dat u op de
website terugkeert', dat moet er natuurlijk uit. Deze kreet zat eerder ook in de
programmatekst en is 'de volgende keer dat u de website bezoekt' geworden.

Of het zinvol is: ik weet niet zeker of er (tegenwoordig nog) via andere
manieren mensen aan werken, maar wijzigen via cvs mag v.z.i.w. wel of is zelfs
de enige methode (?), dus ga gerust je gang. Ik was zoiets ook van plan maar als
jij het wilt doen graag, dan hou ik tijd over voor andere opgevallen kwesties. :)

Was je overigens niet 'pixels' vergeten in je patch? Verder had je de eerste
zinnen met 'toestaan' niet veranderd zag ik. Was dat opzet? Het is nu naar mijn
idee een 'mix' die nog niet optimaal is, liever dus 'het is toegestaan' ->
'toestemming hebben om'. Kun je tot slot nog iets zeggen over het
help(-)verhaal? Ik zou op dat punt graag bewezen ongelijk krijgen namelijk, dat
voelt wat beter. ;)


    
    

    
  
(In reply to comment #132)
> (In reply to comment #131)
> Cookies.xhtml ziet er wel aardig uit. 
Dank je!

> Kleinigheidjes: misschien is het een idee
<snip>
Ja, het is sowieso maar een eerste versie.  Ik heb dit ook min of meer uit het
gevoel gedaan, zonder de Engelse versie ernaast.  Hoe strict willen we aan de
Engelse aanleunen?

> Of het zinvol is: ik weet niet zeker of er (tegenwoordig nog) via andere
> manieren mensen aan werken, maar wijzigen via cvs mag v.z.i.w. wel of is zelfs
> de enige methode (?), dus ga gerust je gang. Ik was zoiets ook van plan maar als
> jij het wilt doen graag, dan hou ik tijd over voor andere opgevallen kwesties. :)

Ik hoef hier geen alleenrecht op hoor...  Maar hoort dit niet thuis onder  bug
293223?

> Was je overigens niet 'pixels' vergeten in je patch? 

Daar zal ik een ander klein patchje van maken.  Het lijkt me te verwarrend om de
dingen uit de helpbestanden en de andere te mengen in ייn patch, net vanwege hun
heel andere aard.

> Verder had je de eerste
<snip>
Zoals gezegd, ik zal er nog eens naar moeten kijken.  Of als iemand anders dat
wil doen, ook graag hoor.

> Kun je tot slot nog iets zeggen over het
> help(-)verhaal? 

Tsja, dat is een beetje een moeilijk geval: het werkwoord is helpen, maar het
zelfstandig naamwoord is hulp.  Je zal in het GB dan ook geen enkele
samenstelling vinden die begint met help-, maar des te meer met hulp-, en
allemaal aan het volgende woord vast.  Ik vind al langer dat we daar overal hulp
van moeten maken, meer 'Help' is jammer genoeg al zo ingeburgerd (een
anglicisme, als je het mij vraagt) dat je daar moeilijk nog onderuit geraakt. 
De GVD heeft enkele voorbeelden met help-, die duidelijk uit de computerwereld
stammen, zoals helptoets, helpscherm en helpfunctie.

Wat mij betreft zou ik overal waar niet rechtstreeks naar het menuonderdeel
'Help' verwezen wordt hulp zien staan, en de voorbeelden van de GVD pleiten
verder voor het aan elkaar schrijven.

Overigens vind ik jullie kritiek op de GVD niet geheel terecht, te meer daar na
de nieuwe spellingwijziging die binnenkort van kracht gaat een deel van de
woorden die de GVD anders spelt dan het GB binnenkort in het GB zullen aangepast
worden...


    
    

    
  
Comment on attachment 186156 [details]
De nieuwe versie van de hulp rond cookies

1: voor de help bestanden is er een apparte bug
2: graag patchen

        Attachment #186156 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186155 [details] [diff] [review]
Een herwerkte versie van cookies.xhtml

patches gebaseerd op 1.0.4 hebben geen zin. Ik heb er niet nauwkeurig naar
gekeken maar de helpbestanden zijn voor een deel herschreven (zie bug 293223)

        Attachment #186155 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #134)
> (From update of attachment 186156 [details] [edit])
> 1: voor de help bestanden is er een apparte bug

Ok, dan ga ik daarheen.

> 2: graag patchen

De patch hangt erboven.

(In reply to comment #135)
> (From update of attachment 186155 [details] [diff] [review] [edit])
> patches gebaseerd op 1.0.4 hebben geen zin. Ik heb er niet nauwkeurig naar
> gekeken maar de helpbestanden zijn voor een deel herschreven (zie bug 293223)

Hoe moet ik dan wel tewerk gaan?


    
    

    
  
(In reply to comment #136)

> Hoe moet ik dan wel tewerk gaan?
> 

Als je geen nightly wilt installeren (wat trouwens geen risico met zich
meebrengt zolang je een appart profiel aanmaakt) kan je de engelse bestanden
natuurlijk ook met je cvs client ophalen (zo doe ik het) of de bestanden
bekijken via internet.
Voor bijvoorbeeld de bestanden in de map browser is het adres:
http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/

Vat het aub niet verkeerd op, je werk wordt zeker gewaardeert maar we moeten
oppassen dat dingen niet de verkeerde kant op veranderen :-)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        rasterpunten; toegestane sites (obsolete)
        — 
          — Splinter Review
      

    


  
Ok, eindelijk zoals beloofd, de patch voor rasterpunten.

Ik ook nog 'Toegestane sites' vervangen door 'Websites met toestemming'. 
'Uitzonderingen' was toch niet zo'n goed idee, want dat wordt alleen gebruikt
indien er zowel geblokkeerd als toegestaan kan worden, terwijl bij het eerste
alleen maar voor al dan niet toelaten gebruikt wordt.  Ook duiken die in het
optiemenu op andere plaatsen op.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Access keys (browser.dtd) (obsolete)
        — 
          — Splinter Review
      

    


  
Enkele wijzigingen voor access keys van hoofd- en bladwijzervenster ter
bevordering van consistentie, plus een paar andere kleine dingen.

    
    

    
  
(In reply to comment #139)
> Created an attachment (id=186356) [edit]
> Access keys (browser.dtd)
> 
> Enkele wijzigingen voor access keys van hoofd- en bladwijzervenster ter
> bevordering van consistentie, plus een paar andere kleine dingen.

Hoe bepaal je eigenlijk die acces keys?  Is hier een regel voor, of gewoon een
letter die redelijk lijkt?  En hoe zorg je ervoor dat er binnen ייn menu niet
verschillende zijn?  Ik heb nl. de indruk dat je weleens dingen uit
verschillende documenten samen in ייn menu hebt, en omgekeerd.

    
    

    
  
(In reply to comment #140)
> Hoe bepaal je eigenlijk die acces keys?  Is hier een regel voor, of gewoon een
> letter die redelijk lijkt?  En hoe zorg je ervoor dat er binnen één menu niet
> verschillende zijn?  Ik heb nl. de indruk dat je weleens dingen uit
> verschillende documenten samen in één menu hebt, en omgekeerd.

Ja er waren wel wat richtlijnen voor, maar die kan ik nu niet meer terugvinden.
Maar het is basically: kies een logische letter (als menu’s in andere
applicaties in Windows vergelijkbare access keys hebben heeft dat de voorkeur),
zorg dat iedere access key uniek is, en vermijd letters die in het menufont erg
smal zijn zoals een l en een i als het even kan (alhoewel dat niet boven alles
gaat, als het gewoon de meest logische keuze is; gewoon doen).

Zorgen dat er geen dubbelen zijn, daarvoor zal je gewoon op moeten letten :).


~Grauw

    
    

    
  


  
Wat losse dingetjes die nog als veranderd aangemerkt op mijn schijf staan, en
xmlparser.properties.

~Grauw

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Vooral Addbookmark.dtd (obsolete)
        — 
          — Splinter Review
      

    


  
Wat kleine dingen die ik lokaal al veranderd had. Vooral creëren vervangen door
aanmaken in Addbookmark.dtd.

    
    

    
  
Comment on attachment 186237 [details] [diff] [review]
rasterpunten; toegestane sites

patch wil niet toegepast worden, maak een patch aub altijd vanuit de nl dir.
(maar wat ik ook probeer met de verschillend -P opties hij wil het niet doen)

    
    

    
  
Comment on attachment 186356 [details] [diff] [review]
Access keys (browser.dtd)

patch toegepast

        Attachment #186356 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186412 [details] [diff] [review]
Dingetjes en xmlparser.properties

patch toegepast

        Attachment #186412 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186454 [details] [diff] [review]
Vooral Addbookmark.dtd

patch toegepast

        Attachment #186454 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 186237 [details] [diff] [review]
rasterpunten; toegestane sites

Patch met de hand ingevoerd (gelukkig was hij niet zo groot ;-) )

        Attachment #186237 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #142)
> Created an attachment (id=186412) [edit]
> Dingetjes en xmlparser.properties
> 
> Wat losse dingetjes die nog als veranderd aangemerkt op mijn schijf staan, en
> xmlparser.properties.

19 = tekenset gespecificeerd _in_ XML-declaratie is incorrect

23 = overwachte parserstaat (geen streepje)

En in het Nl moeten afkortingen in het meervoud steeds een apostrof krijgen:
URI’s, URL’s...

Dit is niet zeer consequent:
XMLParsingError = XML Parsing Error: %1$S\nLocation: %2$S\nLine Number %3$d,
Column %4$d:
+XMLParsingError = XML verwerkingsfout: %1$S\nLocatie: %2$S\nRegelnummer %3$d,
kolom %4$d:
Ofwel Kolom met hoofdletter, ofwel regelnummer zonder.

En ik ben niet zo enthousiast over `troep'.

0.02c, zoals de Ami's het zeggen...
 

    
    

    
  
(In reply to comment #149)
> (In reply to comment #142)
> > Created an attachment (id=186412) [edit] [edit]
> > Dingetjes en xmlparser.properties
> > 
> > Wat losse dingetjes die nog als veranderd aangemerkt op mijn schijf staan, en
> > xmlparser.properties.
> 
> 19 = tekenset gespecificeerd _in_ XML-declaratie is incorrect
> 
> 23 = overwachte parserstaat (geen streepje)
> 
> En in het Nl moeten afkortingen in het meervoud steeds een apostrof krijgen:
> URI’s, URL’s...
> 
> Dit is niet zeer consequent:
> XMLParsingError = XML Parsing Error: %1$S\nLocation: %2$S\nLine Number %3$d,
> Column %4$d:
> +XMLParsingError = XML verwerkingsfout: %1$S\nLocatie: %2$S\nRegelnummer %3$d,
> kolom %4$d:
> Ofwel Kolom met hoofdletter, ofwel regelnummer zonder.
> 
> En ik ben niet zo enthousiast over `troep'.
> 
> 0.02c, zoals de Ami's het zeggen...
>  

opmerkingen doorgevoerd 

    
    

    
  
Omdat deze bug nu erg groot wordt gaan we door in bug 297896.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
    

    
  
(In reply to comment #149)
> Dit is niet zeer consequent:
> XMLParsingError = XML Parsing Error: %1$S\nLocation: %2$S\nLine Number %3$d,
> Column %4$d:
> +XMLParsingError = XML verwerkingsfout: %1$S\nLocatie: %2$S\nRegelnummer %3$d,
> kolom %4$d:
> Ofwel Kolom met hoofdletter, ofwel regelnummer zonder.

Neen, dat klopt niet. Voor kolom staat een komma, voor regelnummer een \n
newline (alhoewel geen punt). Zodoende.

Kolom met een hoofdletter is fout, ik snap ook niet waarom die Engelsen te pas
en te onpas hoofdletters schrijven maar ik ben blij dat dat in het Nederlands
niet het geval is en het feit dat het Engels het met een hoofdletter schrijft
betekent dus niets voor de Nederlandse vertaling.


> En ik ben niet zo enthousiast over `troep'.

Ik ook niet, maar probeer ‘junk’ maar eens beter te vertalen (rommel?), en dit
zat ook in de oude vertaling.


~Grauw

    
    

    
  
(In reply to comment #149)
> 23 = overwachte parserstaat (geen streepje)

Dit had ik expres gedaan omdat ik bij het aan elkaar schrijven aan een ‘staat’
(alsin land) moest denken in plaats van aan ‘status’. Awel.


> En in het Nl moeten afkortingen in het meervoud steeds een apostrof krijgen:
> URI’s, URL’s...

Dat weet ik ook wel, maar ik zie in mijn patch geen voorkomen van URI danwel URL
in het meervoud...


(In reply to comment #150)
> opmerkingen doorgevoerd

Wat heb je precies doorgevoerd?


~Grauw

    
    

    
  
(In reply to comment #152)
> (In reply to comment #149)
> > Dit is niet zeer consequent:
> > XMLParsingError = XML Parsing Error: %1$S\nLocation: %2$S\nLine Number %3$d,
> > Column %4$d:
> > +XMLParsingError = XML verwerkingsfout: %1$S\nLocatie: %2$S\nRegelnummer %3$d,
> > kolom %4$d:
> > Ofwel Kolom met hoofdletter, ofwel regelnummer zonder.
> 
> Neen, dat klopt niet. Voor kolom staat een komma, voor regelnummer een \n
> newline (alhoewel geen punt). Zodoende.
> Kolom met een hoofdletter is fout, ik snap ook niet waarom die Engelsen te pas
> en te onpas hoofdletters schrijven maar ik ben blij dat dat in het Nederlands
> niet het geval is en het feit dat het Engels het met een hoofdletter schrijft
> betekent dus niets voor de Nederlandse vertaling.


ACK.

> > En ik ben niet zo enthousiast over `troep'.
> 
> Ik ook niet, maar probeer ‘junk’ maar eens beter te vertalen (rommel?), en dit
> zat ook in de oude vertaling.

Zoals in TB: ongewenste XXX?

(In reply to comment #153)
> (In reply to comment #149)
> > 23 = overwachte parserstaat (geen streepje)
> 
> Dit had ik expres gedaan omdat ik bij het aan elkaar schrijven aan een ‘staat’
> (alsin land) moest denken in plaats van aan ‘status’. Awel.

Waarom dan niet parserstatus?  Het moet oNverwachte zijn, trouwens.

En ik weet niet wat je met 'awel' wil zeggen, niet op die plaats in de zin,
tenminste.

> > En in het Nl moeten afkortingen in het meervoud steeds een apostrof krijgen:
> > URI’s, URL’s...
> 
> Dat weet ik ook wel, maar ik zie in mijn patch geen voorkomen van URI danwel URL
> in het meervoud...

Er staat zeker ergens URIs in.

    
    

    
  
(In reply to comment #154)
> > > En ik ben niet zo enthousiast over `troep'.
> > 
> > Ik ook niet, maar probeer ‘junk’ maar eens beter te vertalen (rommel?), en dit
> > zat ook in de oude vertaling.
> 
> Zoals in TB: ongewenste XXX?

Dan laat ik het liever zoals het is, dat is duidelijker en makkelijker te
herleiden naar de oorspronkelijke Engelse foutmelding :).


> > Dit had ik expres gedaan omdat ik bij het aan elkaar schrijven aan een ‘staat’
> > (alsin land) moest denken in plaats van aan ‘status’. Awel.
> 
> Waarom dan niet parserstatus?  Het moet oNverwachte zijn, trouwens.

Omdat het niet status is maar ‘staat’ (state).


> En ik weet niet wat je met 'awel' wil zeggen, niet op die plaats in de zin,
> tenminste.

Awel in dit verband betekent uh... awel :). Dat ik het wel even op wil merken
maar dat als anderen het zonder streepje willen dat het mij niet zoveel kan schelen.


> Er staat zeker ergens URIs in.

I stand corrected.


~Grauw

    
    

    
  


  
Wat correcties in xmlparser.properties...

Nog maar even in deze bug omdat ook de oude patch en de betreffende comments
hier staan.

~Grauw

    
    

    
  
Comment on attachment 186596 [details] [diff] [review]
Followup-patch voor xmlparser.properties

patch toegepast

    
    

    
  
(In reply to comment #133)
(ook nog maar even hier vanwege comment-links en eerdere discussie)
> > Kun je tot slot nog iets zeggen over het
> > help(-)verhaal? 
> 
> Tsja, dat is een beetje een moeilijk geval: het werkwoord is helpen, maar...

Eindelijk iemand die het lijkt te begrijpen. ;)

> De GVD heeft enkele voorbeelden met help-, die duidelijk uit de computerwereld
> stammen, zoals helptoets, helpscherm en helpfunctie.

En dat zijn dus zoals gezegd andersoortige termen dan die welke zijn afgeleid
van een functie die 'Help' heet en daarom géén goede leidraad. Een
toets/scherm/venster om hulp te bieden is simpelweg niet hetzelfde als een tot
de functie Help behorend(e) toets/scherm/venster.

Nou ja, ik leg me er wel bij neer en zal deze samen met 'livebladwijzers'
opnemen in het lijstje van 'geaccepteerde fouten', al zag ik dit liever niet
bestaan. :-/ Overigens ben ik van mening dat een uitkomst van een eerdere
discussie pas bindend is als daarin 100% juistheid is aangetoond en dat bij
twijfelgevallen grammaticaal correct zijn voor gaat, evenals bij alle andere
teksten.

Laurens (e.a.): kun je n.a.v. comment #122 nog even reageren over updates/nieuwe
versies? Ik zie hier nog steeds e.e.a. foutgaan..

    
    

    
  
(In reply to comment #158)
> Nou ja, ik leg me er wel bij neer en zal deze samen met 'livebladwijzers'
> opnemen in het lijstje van 'geaccepteerde fouten', al zag ik dit liever niet
> bestaan. :-/

In het vertaalwoordenboek graag,
http://www.mozbrowser.nl/wiki/wiki.phtml?title=Vertaalwoordenboek

:)

(n.b. de wiki heeft een nieuwe stijl zie ik, de tabellen zien er alleen wat
minder uit nu, dat is jammer)


> Overigens ben ik van mening dat een uitkomst van een eerdere
> discussie pas bindend is als daarin 100% juistheid is aangetoond

Echter het heeft geen zin om telkens overnieuw over iets in discussie te gaan.


> Laurens (e.a.): kun je n.a.v. comment #122 nog even reageren over 
> updates/nieuwe versies? Ik zie hier nog steeds e.e.a. foutgaan..

Ah, ja, dat had ik gemist. Gesmokkel, ach, wat is gesmokkel. Zowieso is het
verschil tussen update en upgrade niet zo heel groot, dus gewoon gebruiken wat
in het Nederlands dezelfde betekenis weergeeft en het meest logisch wegleest.

Maar in principe: Upgrade = nieuwe versie en updaten = bijwerken. Maar update
als zelfst. naamwoord ipv. werkwoord kan je niet als ‘bijwerken’ vertalen
natuurlijk (hoogstens als bijgewerkte versie) dus daar gebruik je ook nieuwe
versie voor.

Heb ik dat zo goed?


~Grauw

    
    

    
  
(In reply to comment #159)
> In het vertaalwoordenboek graag,
> http://www.mozbrowser.nl/wiki/wiki.phtml?title=Vertaalwoordenboek
> 

Bedoel je hiermee dat ik die twee termen daarin moet laten toevoegen?

> 
> Echter het heeft geen zin om telkens overnieuw over iets in discussie te gaan.

Dat is naar mijn idee ook niet echt het geval en als het er op lijkt was het
niet mijn bedoeling. Het is zo dat ik ten tijde van de 1.0-vertaling op pagina
17 van het onderwerp 'Verbetering nieuwe Firefox-vertaling' op Mozbrowser een
voorstel deed tot wijziging van 'Help inhoud' naar 'Help-inhoud', en dat
hierover daarna blijkbaar door anderen een discussie is ontstaan waaraan ik
v.z.i.w. niet heb deelgenomen en die als uitkomst 'helpinhoud' had (of en waar
dat zo is weet ik niet eens, daarvoor doe ik te kort mee in bugzilla en ik heb
ook niet in eerdere bugs meegekeken; is de discussie nog ergens terug te
vinden?). In deze bug sneed ik het voor het eerst concreet aan omdat de huidige
oplossing afwijkt van dat voorstel, maar vooral omdat ik geen sluitende
verklaring zag, iets wat altijd welkom is bij grammaticale onduidelijkheden. Er
is dus blijkbaar iets heiligs aan deze term als ik jou zo moet geloven :),
terwijl ik hier ook uitspraken van je lees als

- "ikzelf vind het beter zoals het was, maar het maakt me niet echt veel uit"
- "koppelstreepjes zijn wel enigszins een grijs gebied, waarin ook enige
vrijheid wordt gelaten."
- "Dat ik het wel even op wil merken maar dat als anderen het zonder streepje
willen dat het mij niet zoveel kan schelen."

Als die uitkomst dan zo heilig is (maar best foutief zou kunnen zijn) zou ik ook
graag de bijbehorende sluitende verklaring die verder gaat dan "er is toen
besloten.." zien waarvan ik hoop dat die sterker is dan de mijne, of er een zien
die de mijne onderuit haalt, begrijp je? :)

> 
> Ah, ja, dat had ik gemist. Gesmokkel, ach, wat is gesmokkel. Zowieso is het
> verschil tussen update en upgrade niet zo heel groot, dus gewoon gebruiken wat
> in het Nederlands dezelfde betekenis weergeeft en het meest logisch wegleest.

Hmm.. ik ga er liever wat exacter mee om. :)

> 
> Maar in principe: Upgrade = nieuwe versie en updaten = bijwerken. Maar update
> als zelfst. naamwoord ipv. werkwoord kan je niet als ‘bijwerken’ vertalen
> natuurlijk (hoogstens als bijgewerkte versie) dus daar gebruik je ook nieuwe
> versie voor.
> 
> Heb ik dat zo goed?

Bijna. Ik had tenminste begrepen en ben ook van mening dat vanwege dat laatste
een update gewoon een update zou moeten blijven en er niet gesmokkeld mag
worden. Updaten en update zijn inmiddels geaccepteerde en opgenomen termen in
het Nederlands en ik zou ze daarom allebei graag terugzien, ook omdat ik me niet
zo kan vinden in de reden voor het vermijden ervan (geüpdatet en geüpgraded
zouden te raar staan). Qua betekenis is een nieuwe versie ook iets heel anders
dan een update; een update is meer een 'bijwerking' zoals een patch of security
fix (bijv. 1.0.3 -> 1.0.4) en dan zowel het bestand zelf als de procedure. Een
upgrade is (meestal) het proces van opwaardering naar een hogere versie, ook ná
toepassing van, inderdaad, een update. Vandaar dat zoeken naar updates,
software-update, controleren op updates, updates van extensies etc. denk ik
beter allemaal zo kunnen blijven en de term nieuwe versie pas gebruikt mag
worden waar in het origineel ook over upgrade wordt gesproken, en eventueel de
term upgrade waar mogelijk ook behouden blijft. N.B. Deze consistentie komt het
geheel wellicht ten goede als Firefox straks met patches gaat werken voor het
updaten, i.t.t. het nu nog ophalen van de totale installer. Mee eens?


    
    

    
  
(In reply to comment #160)
> > In het vertaalwoordenboek graag,
> > http://www.mozbrowser.nl/wiki/wiki.phtml?title=Vertaalwoordenboek
> 
> Bedoel je hiermee dat ik die twee termen daarin moet laten toevoegen?

Dat zou prettig zijn, want dat gebruiken we (als het goed is ;p) als overzicht
van lastig te vertalen woorden, waarmee we de consistentie proberen te bewaren.
Als een woord daar in staat, dan is er over nagedacht en elders ook zo vertaald,
en is het dus het beste om die vertaling aan te houden.


> Als die uitkomst dan zo heilig is (maar best foutief zou kunnen zijn) zou ik ook
> graag de bijbehorende sluitende verklaring die verder gaat dan "er is toen
> besloten.." zien waarvan ik hoop dat die sterker is dan de mijne, of er een zien
> die de mijne onderuit haalt, begrijp je? :)

De uitkomst is absoluut niet heilig, maar als er moeilijke dingen zijn besloten
ten tijde van 1.0, en die elke keer weer overnieuw moeten worden uitgelegd
wanneer er bij een nieuwe release nieuwe teamleden bijkomen, dan blijven we
bezig. Vandaar de opmerking in de strekking van, hier hebben we het voor 1.0 al
over gehad, laten we dat niet nog een keer doen.

Zeker bij twistpunten krijg je anders van dat soort situaties waarbij in 1.0
"Helpinhoud" staat, in 1.1 "Help-inhoud" en dat door iemand anders dan in 1.5
weer naar "Helpinhoud" veranderd wordt, etc. Dat staat bovendien ook een beetje
raar voor de gebruiker, als zijn UI met elke versie niet zozeer verbetert, maar
alleen verandert :).

Dat betekent echter niet dat het allemaal in steen gegoten staat - als je er een
punt van wil maken dan mag dat natuurlijk. Zoals ik ten tijde van 1.0
waarschijnlijk ook al zei - het kan me niet zoveel schelen, en de regels zijn
hier niet heel duidelijk over. Waarschijnlijk gold dat wel voor iedereen en dus
hebben we maar deze keuze gemaakt.

Maar aangezien beide schrijfwijzes mij toch om het even zijn, heb ik liever dat
er niks veranderd word, en daar gaf ik uiting aan eerder in deze bug.


> Hmm.. ik ga er liever wat exacter mee om. :)

Dan zeg ik: taal is geen exacte wetenschap :).

Het belangrijkste is dat het samenhangend en consistent is, en niet vreemd op de
gebruiker overkomt, en tegelijkertijd de Nederlandse taal zoveel mogelijk
(correct) gebruikt.

Maar bij dingen zoals Hulp (Help) en Gereedschappen (Tools) menu’s, en termen
zoals opduikvenster of webstek (vrij gangbaar in België, begrijp ik trouwens),
dan gaat het ‘niet vreemd op de gebruiker overkomen’ toch echt boven correct
Nederlands taalgebruik :).


> Bijna. Ik had tenminste begrepen en ben ook van mening dat vanwege dat laatste
> een update gewoon een update zou moeten blijven en er niet gesmokkeld mag
> worden. Updaten en update zijn inmiddels geaccepteerde en opgenomen termen in
> het Nederlands en ik zou ze daarom allebei graag terugzien, ook omdat ik me niet
[...]
> geheel wellicht ten goede als Firefox straks met patches gaat werken voor het
> updaten, i.t.t. het nu nog ophalen van de totale installer. Mee eens?

Nee :). Volgens die redenering is harddisk is ook een redelijk geaccepteerd
woord in het Nederlands, en is er geen reden om harde schijf te gebruiken. Nu
heeft dat niet meteen een vertalingsconflict, maar stel dat dat er wel was, dan
moeten we dat oplossen en niet als een soort van cop-out maar gewoon de Engelse
term gebruiken.

Als we het met Nederlandse woorden kunnen redden, dan moeten we niet gaan
terugvallen op Engels alleen omdat het verschil tussen update en upgrade niet zo
heel precies één op één naar het Nederlands te vertalen is.

Als je per sé een verschil tussen de twee wilt aangeven, gebruik dan nieuwe vs.
bijgewerkte versie. Maar als ik naar de context kijk, dan maakt volgens mij
Firefox geen verschil tussen updates en upgrades, twee woorden die overigens ook
in het Engels te pas en te onpas met dezelfde betekenis door elkaar heen
gebruikt worden.


~Grauw

    
  

        Attachment #186596 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #161)
> (In reply to comment #160)
> > > In het vertaalwoordenboek graag,
> > > http://www.mozbrowser.nl/wiki/wiki.phtml?title=Vertaalwoordenboek

Ik zie hier op de overlegpagina dat er nog wat discussie is over ontvinken dan
wel uitvinken.  Zelf ben ik ook eerder voor het eerste te vinden, maar onlangs
werd ik terechtgewezen dat het vink ... uit moet zijn, en nu ben ik dat in de
helpfiles (zie bug 293223) consequent aan het doorvoeren (i.p.v. demarkeren, wat
er nu vaak staat).  Wordt het niet eens tijd hier ook een concensus over te vinden?

> zoals opduikvenster of webstek (vrij gangbaar in België, begrijp ik trouwens)

Dan heb je dat mis begrepen.  Zelden gehoord.

Wat Hulp en Help betreft: help is een anglicisme.  Het zou ontegensprekelijk
juister en nederlandser zijn om in alle gevallen die niet expliciet naar het
menu Help verwijzen `hulp' te gebruiken (om over het menu Help zelf nog maar te
zwijgen), maar ik denk dat de terminologie althans in de Windowswereld zo
doordrongen is van het woord `help', dat we daar niet meer omheen kunnen.


    
    

    
  
(In reply to comment #162)
> > > > In het vertaalwoordenboek graag,
> > > > http://www.mozbrowser.nl/wiki/wiki.phtml?title=Vertaalwoordenboek
> 
> Ik zie hier op de overlegpagina dat er nog wat discussie is over ontvinken dan
> wel uitvinken.  Zelf ben ik ook eerder voor het eerste te vinden, maar onlangs
> werd ik terechtgewezen dat het vink ... uit moet zijn, en nu ben ik dat in de
> helpfiles (zie bug 293223) consequent aan het doorvoeren (i.p.v. demarkeren, wat
> er nu vaak staat).  Wordt het niet eens tijd hier ook een concensus over te
vinden?

Ja. Wat mij betreft vinden we ter plekke even een woord hiervoor uit (dat is:
ontvinken), maar een bestaand woord zoals demarkeren gebruiken is wellicht beter
(volgens mij heb ik dat in 1.0 zelf zo vertaald :)). Uitvinken daar doe ik een
veto op, hehe ;p.


> > zoals opduikvenster of webstek (vrij gangbaar in België, begrijp ik trouwens)
> 
> Dan heb je dat mis begrepen. Zelden gehoord.

Oh, ik hoorde een keer webstek op VRT (of hoe het nu ook heet), en dat is
blijven hangen.


~Grauw

    
    

    
  
Sterker nog: als het niet teveel problemen oplevert ben ik voorstander van
‘demarkeer’ gebruiken.

~Grauw

    
    

    
  
(In reply to comment #164)
> Sterker nog: als het niet teveel problemen oplevert ben ik voorstander van
> ‘demarkeer’ gebruiken.

Jamaar zeg, ik ben dat hier overal aan het veranderen... ik ben trouwens niet
voor demarkeren, dat overigens volgens Van Dale demarqueren gespeld wordt, en 
	1		begrenzen (1), afbakenen (1)
	2		(biljartspel) punten tellen bij aftrekking
betekent.  Helemaal niet van toepassing dus.

Ik ben voor ontvinken, wie bied meer?

    
    

    
  
Altijd gedacht dat het aan/uit-vinken was.

    
    

    
  
marqueren... mijn god...

Affijn, demarkeren is het tegenovergestelde van markeren: iets van een merkteken
voorzien.

    
    

    
  
(In reply to comment #167)
> marqueren... mijn god...
> 
> Affijn, demarkeren is het tegenovergestelde van markeren: iets van een merkteken
> voorzien.

Neen, net niet.  Demarqueren, zoals het blijkbaar hoort (ook volgens het GB),
betekent: afbakenen.  Totaal niet van toepassing dus.  Wel vreemde spelling
overigens, want markeren is wel met k.

    
    

    
  
(In reply to comment #161)
> (In reply to comment #160)
> 
> Dat zou prettig zijn, want dat gebruiken we (als het goed is ;p) als overzicht
> van lastig te vertalen woorden, waarmee we de consistentie proberen te bewaren.
> Als een woord daar in staat, dan is er over nagedacht en elders ook zo vertaald,
> en is het dus het beste om die vertaling aan te houden.

Dan zul je ook begrijpen (en vat dit niet verkeerd op) dat ik dat liever iemand
anders zie doen. Ik gaf aan dat het twee gevallen zijn die ik persoonlijk
moeilijk (/niet) kan accepteren omdat ze technisch niet kloppen en dat ik ze
derhalve op een (virtueel) lijstje van geaccepteerde fouten heb gezet. De wiki
is er blijkbaar voor twijfelgevallen en lastig te vertalen woorden en heeft als
doel hetzelfde denkwerk een volgende keer te vermijden door een bindende
uitkomst te creëren dus a) ik geloof niet dat de twee gevallen hiervoor in
aanmerking komen, b) ben ik bang dat er dan helemaal geen discussie meer over
mogelijk is en c) wordt niet voldaan aan je definities hierboven (m.b.t.
nadenken en vertaling elders). Daarbij wilde ik mijn taak beperken tot het
optimaliseren van de vertaling zelf en niet uitbreiden met dergelijke zaken.
Overigens vind ik de kwaliteit van de op de wiki gebruikte spelling erg slecht
en heb ik ook geen vertrouwen in de juistheid van sommige vertalingen daarin tot
nu toe.

> 
> De uitkomst is absoluut niet heilig, maar als er moeilijke dingen zijn besloten
> ten tijde van 1.0, en die elke keer weer overnieuw moeten worden uitgelegd
> wanneer er bij een nieuwe release nieuwe teamleden bijkomen, dan blijven we
> bezig. Vandaar de opmerking in de strekking van, hier hebben we het voor 1.0 al
> over gehad, laten we dat niet nog een keer doen.
> 

Begrijpelijk, maar dat is voor jou een weet en voor mij niet, vandaar dat ik
vroeg of die uitleg ergens was terug te vinden omdat hij hier tot nu toe nog
steeds niet werd gegeven; ik zag zoals gezegd niet meer dan "er is toen besloten
omdat de meesten het wel goed vonden". Vervolgens leek de term heilig terwijl er
blijkbaar ook niet goed over was nagedacht. Overigens had ik graag gezien dat
destijds naar mijn mening werd gevraagd, te meer daar het afweek van mijn gedane
voorstel (met koppelteken).
 
> Zeker bij twistpunten krijg je anders van dat soort situaties waarbij in 1.0
> "Helpinhoud" staat, in 1.1 "Help-inhoud" en dat door iemand anders dan in 1.5
> weer naar "Helpinhoud" veranderd wordt, etc. Dat staat bovendien ook een beetje
> raar voor de gebruiker, als zijn UI met elke versie niet zozeer verbetert, maar
> alleen verandert :).
> 

Onzin, vasthouden aan een vertaling van eerdere versies is geen reden. Net als
bij andere termen is er niks mis met het grammaticaal optimaliseren ervan en is
er dus enkel sprake van verbetering. Zodra er bovendien duidelijkheid over
bestaat is het uitgesloten dat er in 1.5 weer wordt veranderd en als je daar
bang voor bent zou je de term alsnog (maar dan terecht) in de wiki op kunnen
nemen. En raar? Ook al zullen er misschien een paar mensen even opkijken van
(iedere) verandering, er zullen nu, maar misschien nog meer als 1.5 er is, meer
MS-gebruikers raar opkijken bij het zien van 'Helpinhoud' dan bij 'Help-inhoud'
nadat ze zijn overgestapt. :)

> Dat betekent echter niet dat het allemaal in steen gegoten staat - als je er een
> punt van wil maken dan mag dat natuurlijk.

Bij deze dus. Ik vraag me nu enkel nog af wat er voor nodig is om de term wel
veranderd te krijgen.

> Zoals ik ten tijde van 1.0
> waarschijnlijk ook al zei - het kan me niet zoveel schelen, en de regels zijn
> hier niet heel duidelijk over. Waarschijnlijk gold dat wel voor iedereen en dus
> hebben we maar deze keuze gemaakt.
> 

Precies, en hier niet meer van afwijken is dus een onbuigzaamheid die ik niet
kan begrijpen. Misschien alleen omdat de term in het hoofdmenu staat? Hoe dan
ook, ik begrijp dat dit de beste uitleg is tot nu toe en dus vind ik het jammer
als die bepalend is. Ook begrijp ik nog steeds niet dat je regelmatig (nu ook
weer) uitspraken doet als "niet zo veel kunnen schelen" e.d.

> Maar aangezien beide schrijfwijzes mij toch om het even zijn, heb ik liever dat
> er niks veranderd word, en daar gaf ik uiting aan eerder in deze bug.
> 

Dat bedoel ik. Hoe zou jij het vinden als ik of anderen dit zouden zeggen over
andere termen? Neem liever een uit regels afgeleid standpunt in zou ik zeggen en
bepaal daaruit een voorkeur, en hou dergelijke wijzigingen niet tegen als ze
goed zijn onderbouwd.

> 
> Dan zeg ik: taal is geen exacte wetenschap :).

Maar er valt in principe niet over te twisten. Iets is goed of het is fout en
het komt maar zelden voor dat dit niet zo is. Als dat het geval is zouden er
twee of meer interpretaties van regels strijdig moeten zijn en ik mis tot nu toe
de tweede.

> 
> Het belangrijkste is dat het samenhangend en consistent is, en niet vreemd op de
> gebruiker overkomt, en tegelijkertijd de Nederlandse taal zoveel mogelijk
> (correct) gebruikt.

Ik denk (en weet wel zeker) dat algemeen geaccepteerde Engelse woorden minder
vreemd op de gebruiker overkomen dan bepaalde vertalingen en dat zullen anderen
hier wellicht ook vinden. Hoe vaak ik alleen gisteren alleen al het woord 
'update' op Nederlandstalige websites, in softwareprogramma's en zelfs in
radioreclames heb gezien/gehoord..

> 
> Nee :). Volgens die redenering is harddisk is ook een redelijk geaccepteerd
> woord in het Nederlands, en is er geen reden om harde schijf te gebruiken. Nu
> heeft dat niet meteen een vertalingsconflict, maar stel dat dat er wel was, dan
> moeten we dat oplossen en niet als een soort van cop-out maar gewoon de Engelse
> term gebruiken.

Dit is enkel zo omdat 'harde schijf' inmiddels aardig is ingeburgerd, en dan nog
prefereer ik zelf harddisk (Van Dale kent deze term ook, evenals upgrade en
update overigens). Een update is zowel een onvervangbaar als geaccepteerd woord
en er lijkt me in dit geval dus zeker geen sprake van een cop-out. Ik begin te
geloven dat jij liever een 100% Nederlandse vertaling ziet waarin anderstalige
termen zijn uitgesloten (een beetje op zijn Vlaams zogezegd, no offense),
terwijl ik pleit voor toepassing van algemeen geaccepteerd taalgebruik.

> 
> Als we het met Nederlandse woorden kunnen redden, dan moeten we niet gaan
> terugvallen op Engels alleen omdat het verschil tussen update en upgrade niet zo
> heel precies één op één naar het Nederlands te vertalen is.
> 

Dat verschil staat hierboven uitgelegd (gebruik anders Google even) en bestaat
wel degelijk, dus hierin mag naar mijn mening zeker niet gerommeld worden; het
is ook niet voor niets dat de KDE-vertaling ook een verschil aangeeft die
enigszins matcht met mijn uitleg en het lijkt erop dat jij dit kleine verschil
er nu uit probeert te halen. Dat deze twee termen allebei in het Nederlands ook
worden gebruikt elimineert dus het vertaalprobleem en houdt bovendien de
duidelijkheid erin.

> Als je per sé een verschil tussen de twee wilt aangeven, gebruik dan nieuwe vs.
> bijgewerkte versie.

Iets met versie is zowiezo fout vind ik, dan wel een noodoplossing.

> Maar als ik naar de context kijk, dan maakt volgens mij
> Firefox geen verschil tussen updates en upgrades, twee woorden die overigens ook
> in het Engels te pas en te onpas met dezelfde betekenis door elkaar heen
> gebruikt worden.
> 

Even beter kijken dan, zie boven. En waar het Engels het door elkaar heen
gebruikt is dat ook fout en voor ons geen reden om dit op deze manier te verergeren.

    
    

    
  
(In reply to comment #165)

> Ik ben voor ontvinken, wie bied meer?

Aan/uitvinken is naar mijn mening de beste oplossing.

Ten eerste mag je niet zomaar iets van 'ont' voorzien, los al van het feit dat
de tegenhanger daarvan de vorm zonder 'ont' moet zijn. 'Afvinken' is zoiets als
wegstrepen op een lijst en heeft niks te maken met het 'markeren' dat wordt
bedoeld met het 'aan-/uitschakelen' zoals hier. Zie ook Google-resultaat #1
(taaltelefoon).

    
    

    
  
(In reply to comment #170)
> (In reply to comment #165)
> 
> > Ik ben voor ontvinken, wie bied meer?
> 
> Aan/uitvinken is naar mijn mening de beste oplossing.
> 
> Ten eerste mag je niet zomaar iets van 'ont' voorzien

Waarom niet?  Wanneer mag dat wel/niet?  Taal is een levend ding, hoor.

> Zie ook Google-resultaat #1
> (taaltelefoon).

Geen idee welk Google-resultaat je bedoelt, maar beide komen voor.  Googlefight
geeft wel een duidelijk voordeel voor uitvinken, waaruit ik concludeer dat het
gangbaarder is, dus ik leg me neer bij aan-/uitvinken.


    
    

    
  
(In reply to comment #169)
<snip een heleboel>
> MS-gebruikers raar opkijken bij het zien van 'Helpinhoud' dan bij 'Help-inhoud'
> nadat ze zijn overgestapt. :)

Waar haal je dat vandaan?  Ik zie in geen enkel MS-programma Help-inhoud, dan
wel Helpinhoud staan.  Meestal iets als MS X Help.

Maar voor alle duidelijkheid: ik ben het absoluut ONeens met Help-inhoud.  Er is
geen reden whatsoever (om het met een nog niet ingeburgerd Engels woord te
zeggen ;-)) om daar een streepje te zetten.

> > Dat betekent echter niet dat het allemaal in steen gegoten staat - als je er een
> > punt van wil maken dan mag dat natuurlijk.
> 
> Bij deze dus. 

Wat mij betreft ook.

> Maar er valt in principe niet over te twisten. Iets is goed of het is fout en
> het komt maar zelden voor dat dit niet zo is. 

Dat is redelijk in strijd met de hedendaagse taalkundige inzichten, vrees ik. 
Goed en fout in taal zijn zo goed als onbestaande.  Wat er wel bestaat zijn
adviezen en voorschriften, en in hoeverre je je daaraan houdt.

Wat betreft update vs. opgrade: hier heb ik geen problemen mee, deze woorden
zijn al genoeg ingeburgerd.  Maar harddisk vind ik dan weer echt onnodig, er is
toch hoegenaamd geen betekenisverschil met harde schijf?  Nu ja, dan zie je maar
hoe dun de grens is.

    
    

    
  
(In reply to comment #171)
>
> Waarom niet?  Wanneer mag dat wel/niet?  Taal is een levend ding, hoor.

Maar zo levend ook weer niet, dit lijkt me meer op een geval van zelf verzinnen.
'Ont' is meestal een tegenhanger van 'be' en hoewel er vaak kloppende
verklaringen kunnen worden gegeven aan iets nieuws met 'ont' is dit meestal een
geval van (nog) niet bestaande of ingeburgerde werkwoorden en alleen dat al is
een reden om het te vermijden.

> Geen idee welk Google-resultaat je bedoelt, maar beide komen voor.  

http://taaltelefoon.vlaanderen.be/indekijker/vraagvandeweek/archiefvraagvandeweek/afvinken.htm


    
    

    
  
(In reply to comment #173)
> (In reply to comment #171)
> >
> > Waarom niet?  Wanneer mag dat wel/niet?  Taal is een levend ding, hoor.
> 
> Maar zo levend ook weer niet, dit lijkt me meer op een geval van zelf verzinnen.

Natuurlijk.  Volledig zelf verzonnen. 

> 'Ont' is meestal een tegenhanger van 'be' en hoewel er vaak kloppende
> verklaringen kunnen worden gegeven aan iets nieuws met 'ont' is dit meestal een
> geval van (nog) niet bestaande of ingeburgerde werkwoorden en alleen dat al is
> een reden om het te vermijden.

Ok, in een contexst als deze ben ik het daar mee eens.  Maar dingen die ik in
mijn eigen naam schrijf, zal ik er niet voor terugschrikken.

> > Geen idee welk Google-resultaat je bedoelt, maar beide komen voor.  
http://taaltelefoon.vlaanderen.be/indekijker/vraagvandeweek/archiefvraagvandeweek/afvinken.htm

Ok, dit is overtuigend, uitvinken it shall be.


    
    

    
  
(In reply to comment #172)
> Waar haal je dat vandaan?  Ik zie in geen enkel MS-programma Help-inhoud, dan
> wel Helpinhoud staan.  Meestal iets als MS X Help.
> 

Zoek in Windows (i.i.g. 98, XP weet ik niet zeker maar dacht van wel) naar
'help' of op Google naar 'help-inhoud' en zie dat MS overal een koppelteken
hanteert, daar waar het refereert aan het onderdeel Help. In IE zelf niet, dat
klopt, maar in de Help en op al hun websites wel. Men kan een hoop over MS
zeggen, maar niet dat ze slecht zijn in hun vertalingen en dat lijkt in dit
geval ook op te gaan.

> Maar voor alle duidelijkheid: ik ben het absoluut ONeens met Help-inhoud.  Er is
> geen reden whatsoever (om het met een nog niet ingeburgerd Engels woord te
> zeggen ;-)) om daar een streepje te zetten.
> 

Wel als je het ziet als een samenstelling met een eigennaam, à la Mozilla-forum,
Fiat-uitlaat etc. en dat doet MS waarschijnlijk ook. En terecht denk ik, want
het streepje dient om die scheiding te benadrukken/behouden en verwarring met
'een inhoud die bedoeld is om te helpen' te voorkomen (ook al is de betekenis
toevallig bijna hetzelfde). Wat misschien wel zo is, is dat de regels hier
onduidelijk over lijken te zijn, maar de aanname dat 'help' hier voor 100% als
het eerste deel van een normale samenstelling mag worden gezien is simpelweg
onjuist, ben ik bang. Is het een eigennaam dan is er niets mis mee.

> Goed en fout in taal zijn zo goed als onbestaande.  Wat er wel bestaat zijn
> adviezen en voorschriften, en in hoeverre je je daaraan houdt.

Ik wens me daar altijd graag aan te houden en alleen met goede reden daarvan af
te wijken. :)

    
    

    
  
(In reply to comment #175)
> (In reply to comment #172)
> > Waar haal je dat vandaan?  Ik zie in geen enkel MS-programma Help-inhoud, dan
> > wel Helpinhoud staan.  Meestal iets als MS X Help.
> > 
> 
> Zoek in Windows (i.i.g. 98, XP weet ik niet zeker maar dacht van wel) naar
> 'help' of op Google naar 'help-inhoud' en zie dat MS overal een koppelteken
> hanteert, daar waar het refereert aan het onderdeel Help. In IE zelf niet, dat
> klopt, maar in de Help en op al hun websites wel. Men kan een hoop over MS
> zeggen, maar niet dat ze slecht zijn in hun vertalingen en dat lijkt in dit
> geval ook op te gaan.
> 
> > Maar voor alle duidelijkheid: ik ben het absoluut ONeens met Help-inhoud.  Er is
> > geen reden whatsoever (om het met een nog niet ingeburgerd Engels woord te
> > zeggen ;-)) om daar een streepje te zetten.
> 
> Wel als je het ziet als een samenstelling met een eigennaam, à la Mozilla-forum,
> Fiat-uitlaat etc. en dat doet MS waarschijnlijk ook. En terecht denk ik, want
> het streepje dient om die scheiding te benadrukken/behouden en verwarring met
> 'een inhoud die bedoeld is om te helpen' te voorkomen (ook al is de betekenis
> toevallig bijna hetzelfde). Wat misschien wel zo is, is dat de regels hier
> onduidelijk over lijken te zijn, maar de aanname dat 'help' hier voor 100% als
> het eerste deel van een normale samenstelling mag worden gezien is simpelweg
> onjuist, ben ik bang. Is het een eigennaam dan is er niets mis mee.

Ok, nu snap ik eindelijk hoe je ertoe komt daar een streepje te willen zetten.
Maar ik vind het geen overtuigend argument, omdat ik het wat vreemd vind om
`Help' als een eigennaam op te vatten.  Waarom gebruiken we (althans in het
menu) dan niet gewoon Inhoud, zonder meer?  Het is toch al duidelijk dat het om
de Help gaat, want het zit onder dat menu...
Overigens vind ik hier ook de redenering wel steek houden dat we niet constant
moeten veranderen; zo staat er op heel wat fora bv. al een verwijzing naar
Helpinhoud...

> > Goed en fout in taal zijn zo goed als onbestaande.  Wat er wel bestaat zijn
> > adviezen en voorschriften, en in hoeverre je je daaraan houdt.
> 
> Ik wens me daar altijd graag aan te houden en alleen met goede reden daarvan af
> te wijken. :)

Tuurlijk, ik ook. Maar zeggen dat er iets bestaat als juiste taal, dat kan ik
niet toestaan ;-)

    
    

    
  
(In reply to comment #169)
> Dan zul je ook begrijpen (en vat dit niet verkeerd op) dat ik dat liever iemand
> anders zie doen.

Een wiki is voor *iedereen*, en kan door iedereen veranderd worden. Niemand
heeft daar in zijn eentje controle over.

Zie je daar foute dingen in staan, suggereer dan correcties in plaats van de
wiki maar te dumpen als waardeloos. Zonder de wiki hebben we *geen* overzicht
van vertalingen, en gaat iedereen maar zijn eigen gangetje.

Als iedereen zijn eigen gangetje gaat dan wordt dat een wanorde, iedereen kan
lekker zijn eigen vertalingen doordrukken zonder dat daarover gediscussieerd
wordt, of er wordt juist over dingen waar al een oplossing voor was gevonden
overnieuw gediscussieerd. En als ik vervolgens iets ga vertalen heb ik geen idee
wat jij of iemand anders over het algemeen als vertaling voor bepaalde woorden
hebt gebruikt.

Volgens mij neem je dit iets te hoog op. Kalmeer, en maak gewoon je punt in
korte argumenten, want reacties zoals deze zijn mij zowel te lang om helemaal
door te lezen, en de toon is mij ook iets te ‘opgewonden’, if you don’t mind me
saying. Zoals ik al zei, het maakt mij niet zoveel uit, en we zijn hier allemaal
‘reasonable human beings’. Je angst dat zodra iets in de wiki terecht komt het
gegoten is in steen is ongegrond.

Maar gebruik wel goede argumenten, bereik een consensus (dat betekent ook: je
ergens af en toe bij neer leggen), en plaats dat vervolgens op de wiki zodat we
deze discussie niet over 6 maanden overnieuw hebben.

Ons doel hier is heel pragmatisch: oplossingen vinden. Perfectie is onmogelijk,
en er zijn verschillende inzichten mogelijk, dus de uiteindelijke oplossing is
vaak een compromis. Accepteer dat dan ook wel.


~Grauw

p.s. over het niet terug kunnen vinden van redenaties; voor 1.0 hebben een
aantal discussies over de vertaling ook over IRC plaatsgevonden. Dat er in
Bugzilla dus weinig over gezegd is betekent niet dat er niet over is nagedacht.

    
    

    
  
(In reply to comment #176)
> 
> Ok, nu snap ik eindelijk hoe je ertoe komt daar een streepje te willen zetten.
> Maar ik vind het geen overtuigend argument, omdat ik het wat vreemd vind om
> `Help' als een eigennaam op te vatten.  Waarom gebruiken we (althans in het
> menu) dan niet gewoon Inhoud, zonder meer?  Het is toch al duidelijk dat het om

Het overtuigt mij ook niet voor 100% maar ik zie er wel een logica in. Alleen
Inhoud: geen idee, en eigenlijk geen mening. :)

> Overigens vind ik hier ook de redenering wel steek houden dat we niet constant
> moeten veranderen; zo staat er op heel wat fora bv. al een verwijzing naar
> Helpinhoud...

Dat is ook wel zo.. (alhoewel fora gewijzigd kunnen worden :))

> 
> Tuurlijk, ik ook. Maar zeggen dat er iets bestaat als juiste taal, dat kan ik
> niet toestaan ;-)

Alhoewel het niet zo werd gezegd heb je hierin wel gelijk. ;)

    
    

    
  
(In reply to comment #177)

Wiki: okee, ik wilde hem niet afkraken op inhoud en nut, doelde meer op
gebruikte spelling. het nut ervan is me duidelijk, enkel het toevoegen van een
misschien fout gespeld woord zat me dwars. Het zou wat vreemd voelen als ik nu
een term toevoeg, die later door anderen misschien wel gewijzigd wordt omdat ie
dan toch fout zou blijken te zijn..

Te hoog opnemen: klopt ten dele wel. Alhoewel die acceptatie er wel was zocht ik
alleen naar de verklaring en draafde daarin misschien wat door, ook wat lengte
betreft, sorry daarvoor. De toon kon inderdaad wat beter zag ik later; vol
overtuiging een bepaalde gedachtengang intikken komt vaak wat onvriendelijk over
dan bedoeld, althans als ik het doe. :]

Compromis: het moge inmiddels duidelijk zijn dat ik me ondanks de vraag over de
juistheid bij de huidige vorm had neergelegd. Dat lukt me ook nog wel. ;)

IRC en nadenken: dat bedacht ik me ook nog. Het moet hier trouwens ook werken
dus zal binnenkort eens een kijkje nemen. Kan misschien ook handig zijn i.v.m.
het eerder beloofde lijstje van grammaticale zaken en inconsistenties dat
misschien te lang/onhandig (en 'open'?) wordt voor Mozbrowser.


    
    

    
  
(In reply to comment #179)
> Wiki: okee, ik wilde hem niet afkraken op inhoud en nut, doelde meer op
> gebruikte spelling. het nut ervan is me duidelijk, enkel het toevoegen van een
> misschien fout gespeld woord zat me dwars. Het zou wat vreemd voelen als ik nu
> een term toevoeg, die later door anderen misschien wel gewijzigd wordt omdat ie
> dan toch fout zou blijken te zijn..

Wiki’s zijn van nature in een staat van ‘flux’. De wiki geeft de huidige
vertaalmethode weer, maar als daar ondertussen over gediscussieerd wordt en hij
na een paar dagen weer veranderd wordt, is dat niet erg.


> IRC en nadenken: dat bedacht ik me ook nog. Het moet hier trouwens ook werken
> dus zal binnenkort eens een kijkje nemen. Kan misschien ook handig zijn i.v.m.
> het eerder beloofde lijstje van grammaticale zaken en inconsistenties dat
> misschien te lang/onhandig (en 'open'?) wordt voor Mozbrowser.

Ik ben er ook lang niet altijd hoor... Ten tijde van 1.0 was ik er vaker.

Wat betreft discussie, ik denk dat je dat het beste op de discussiepagina van de
wiki kunt doen. Dat is wat minder vluchtig, en meer ‘op locatie’. En als je hier
even zegt dat je daar hebt gepost zullen er ook wel voldoende mensen naar
kijken. Denk ik :). Zorg daarbij wel dat je afzonderlijke punten goed
categoriseert, reacties goed indent met :, en je naam bij reacties plaatst met
~~~~, anders wordt het al snel onduidelijk :).


~Grauw

    
    

    
  
(In reply to comment #180)
> Wat betreft discussie, ik denk dat je dat het beste op de discussiepagina van de
> wiki kunt doen. Dat is wat minder vluchtig, en meer ‘op locatie’. En als je hier
> even zegt dat je daar hebt gepost zullen er ook wel voldoende mensen naar
> kijken. Denk ik :). Zorg daarbij wel dat je afzonderlijke punten goed
> categoriseert, reacties goed indent met :, en je naam bij reacties plaatst met
> ~~~~, anders wordt het al snel onduidelijk :).

Om hier maar meteen op in te gaan: ik heb een itempje gepost rond drop-down menu.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: