Closed Bug 653758 Opened 13 years ago Closed 7 years ago

[nl] mozilla-aurora/nl firefox

Categories

(Mozilla Localizations :: nl / Dutch, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mad_maks, Unassigned)

References

Details

Attachments

(44 obsolete files)

Bug voor de verbeteringen in het Aurora-kanaal

http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl
Verbeteringen voor Firefox 5 voor 16 mei 2011 in deze bug plaatsen.
Attached patch Kleinigheidjes (obsolete) — Splinter Review
Ton deze patch ga ik zeker toepassen voor Firefox 6 en ik ben aan het uitzoeken of en hoe ik hem nog kan toepassen voor Firefox 5 (beta).

In deze bug gaan we vanaf vandaag verder werken aan Firefox 6 (aurora wordt vandaag bijgewerkt vanuit central)
Comment on attachment 534686 [details] [diff] [review]
Kleinigheidjes

toegepast op beta en aurora
Attachment #534686 - Attachment is obsolete: true
aurora is weer samengegaan met central, deze bug is nu voor Firefox 7
Wat te doen met correcties voor 5 en 6?
(In reply to comment #6)
> Wat te doen met correcties voor 5 en 6?

5 kan niet meer aangepast worden, 6 vervangt 5 over een paar weken en in principe wordt die ook niet meer aangepast. Maar als je iets zeer fout hebt gevonden bied het aan dan hier aan voor 7 en ik zal het ook nog aanpassen voor 6

maar werk vooruit en controleer aurora, deze is taaltechnisch stabiel (er komen geen nieuwe ui strings meer bij) en daar hebben we 6 weken om alle fouten eruit te halen voordat het beta wordt.
Comment on attachment 548062 [details] [diff] [review]
Correcties en enkele aanpassingen d.d. 24-7

toegepast op aurora en central, beta volgt (hopelijk)
Attachment #548062 - Attachment is obsolete: true
I'm not sure that the messages around the dom attributes element are helpful. Like, appendChild isn't deprecated, but the dom attributes and methods on attributes. Those messages are hard, but I'm not sure that making them more generic is helpful?
Attached patch Dom attribute string fixes (obsolete) — Splinter Review
(In reply to comment #10)
> I'm not sure that the messages around the dom attributes element are
> helpful. Like, appendChild isn't deprecated, but the dom attributes and
> methods on attributes. Those messages are hard, but I'm not sure that making
> them more generic is helpful?

Agreed, thank you for noticing. It wasn’t really a way of making things more generic, but the French locale appeared to have those shortened in a similar way. Must have looked wrong or at certain strings only…

If using attributes on attributes is technically correct, the patch should fix it. Could you check again?
Comment on attachment 549604 [details] [diff] [review]
Dom attribute string fixes

.attributes is the real programming object, see https://developer.mozilla.org/En/DOM/Node.attributes, and http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1780488922.

That apparently used to support some set of node-like DOM methods and properties, which are now phased out.

I suppose that translating the DOM property name .attributes is not what you'd usually do?
(In reply to comment #12)

> I suppose that translating the DOM property name .attributes is not what
> you'd usually do?

Not sure what you mean by that?

(Note that ‘in’ lacks in line 88.)
I think it should be something like
Gebruik van parentNode-attribuut op attributes wordt afgeraden. Het geeft altijd null.
instead of
Gebruik van parentNode-attribuut op attribuut wordt afgeraden. Het geeft altijd null.
Attached patch Dom attribute string fixes v2 (obsolete) — Splinter Review
(In reply to comment #14)
> I think it should be something like…

Well, if you mean the plural issue as used in German (‘auf Attributen’), I think this is not a real issue. French uses a single form as well (‘auf einem Attribut’) and it may be locale specific. Or do I miss the point again here? ;)

I did change one occurrance of ‘attributes’ in AttributesWarning though (and the nit in line 88). Is that what you were referring to?
Attachment #549604 - Attachment is obsolete: true
attributes is not the plural of attribute here. It's `attributes` as in the DOM api property, in nsIDOMNode,

...
  readonly attribute nsIDOMNode       nextSibling;
  readonly attribute nsIDOMNamedNodeMap attributes;
  // Modified in DOM Level 2:
  readonly attribute nsIDOMDocument   ownerDocument;
  nsIDOMNode                insertBefore(in nsIDOMNode newChild, 
                                         in nsIDOMNode refChild)
                                          raises(DOMException);
...

If French gets that wrong, we'll need to harrass them, too ;-)
Could you try explaining one of those strings in normal English, and without the programming talk please, maybe followed in German? If I understand you well now, something tells me most lines in German are incorrect at this point. Using tech terms when elaborating doesn’t ring a bell here (despite the background…) ;)

(Maybe some developers should think about this when creating the strings…)
Oops, sorry, I misunderstood the strings myself. Great ;-).

Exodus of Attribute nodes it is, so Node methods on Attr are deprecated.

someElement.getAttributeNode('src').nextSibling warns that using nextSibling on an attribute is deprecated.
(In reply to comment #9)
> Comment on attachment 548062 [details] [diff] [review] [diff] [details] [review]
> Correcties en enkele aanpassingen d.d. 24-7
> 
> toegepast op aurora en central, beta volgt (hopelijk)

http://hg.mozilla.org/releases/l10n/mozilla-beta/nl/rev/44198b0904c3 helaas was het net te laat voor beta 4. hopelijk komt er nog een beta 5

Ton wat is de status van de nog openstaande patch, ben je eruit met Pike?
(In reply to comment #19)

> Ton wat is de status van de nog openstaande patch, ben je eruit met Pike?

Een beetje onduidelijk nog. Volgens mij is het redelijk vertaald (en net zo als in het Duits), maar de codetalk komt bij mij over als scheikunde. ;)

Pike, did you mean it’s ok now, or should there be another change?
The attachment 549691 [details] [diff] [review] looks OK as far as I can make sense of dutch.
Comment on attachment 549691 [details] [diff] [review]
Dom attribute string fixes v2

toegepast op aurora en central
Attachment #549691 - Attachment is obsolete: true
We gaan nu weer verder voor Firefox 8. Firefox 7 is nu in beta en daar doen we in principe geen aanpassingen meer aan.
Als Firefox (7 beta en 8 aurora) een 'Server niet gevonden'-melding geeft, dan wordt bij het eerste item de punt op de volgende regel weergegeven. Ik heb even de source bekeken en op regel 20 van nl/mail/chrome/overrides/netError.dtd komt er een punt na </li> wat deze fout veroorzaakt. Deze moet natuurlijk binnen de tags staan.

Ik neem aan dat Firefox ook uit nl/mail leest, want dit is de enige plek waar ik wat kon vinden via mxr.

Ik heb geen SVN etc. meer geïnstalleerd, dus kan zo snel niet een patch maken.
(In reply to Gert-Paul van der Beek from comment #24)
> Als Firefox (7 beta en 8 aurora) een 'Server niet gevonden'-melding geeft,
> dan wordt bij het eerste item de punt op de volgende regel weergegeven. Ik
> heb even de source bekeken en op regel 20 van
> nl/mail/chrome/overrides/netError.dtd komt er een punt na </li> wat deze
> fout veroorzaakt. Deze moet natuurlijk binnen de tags staan.
> 
> Ik neem aan dat Firefox ook uit nl/mail leest, want dit is de enige plek
> waar ik wat kon vinden via mxr.
> 
> Ik heb geen SVN etc. meer geïnstalleerd, dus kan zo snel niet een patch
> maken.

Firefox gebruikt geen mailbestanden maar het bestand waar jij naar verwijst bestaat ook in firefox; http://mxr.mozilla.org/l10n-central/source/nl/browser/chrome/overrides/netError.dtd

en in http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/overrides/netError.dtd zie je dat het inderdaad een foutje in de vertaling is. ik ga het meenemen in de volgende commit. Bedankt.
(In reply to Gert-Paul van der Beek from comment #24)
> Als Firefox (7 beta en 8 aurora) een 'Server niet gevonden'-melding geeft,
> dan wordt bij het eerste item de punt op de volgende regel weergegeven. Ik
> heb even de source bekeken en op regel 20 van
> nl/mail/chrome/overrides/netError.dtd komt er een punt na </li> wat deze
> fout veroorzaakt. Deze moet natuurlijk binnen de tags staan.
> 
> Ik neem aan dat Firefox ook uit nl/mail leest, want dit is de enige plek
> waar ik wat kon vinden via mxr.
> 
> Ik heb geen SVN etc. meer geïnstalleerd, dus kan zo snel niet een patch
> maken.

fixed: http://hg.mozilla.org/l10n-central/nl/rev/7a3e2e0aa8ff
firefox 8 is in beta, deze bug is nu voor firefox 9
Via gathering.tweakers.net/forum/list_message/37091084#370910841 merkte ik op dat in http://mxr.mozilla.org/l10n-central/source/nl/toolkit/chrome/mozapps/extensions/selectAddons.dtd confirm.description en select.description niet correct Nederlands zijn: selecteerd -> selecteert.
Schandalig, en dat merken we dus via Tweakers… ;(

Ik ben overigens bang dat er nog meer niet in orde is in de 8-versies. Wat dacht je bv. van de ontbrekende komma in deze zin, of “ingeschakled” in hetzelfde bestand? Nou ja, laten we het er maar op houden dat in 9 alles weer ok is. ;)
(In reply to Ton from comment #29)
> Schandalig, en dat merken we dus via Tweakers… ;(
Schandalig inderdaad, de fout (mijn fout!) zit er al zeker 12 weken in. Ik vertaal (met mijn heerlijke dyslectische fouten) alles in central zodat we in ieder geval een vertaalde versie hebben. Daarna is er de aurora cyclus en de beta cyclus waarin ik hoop feedback tekrijgen van aurora en beta gebruikers (of mensen die de commits volgen) maar blijkbaar is er niemand meer in de nl gemeenschap die het belangrijk vind dat er een goede nl versie is. Pas als het publiekelijk is gaat men roepen dat het fout is


> 
> Ik ben overigens bang dat er nog meer niet in orde is in de 8-versies. Wat
> dacht je bv. van de ontbrekende komma in deze zin, of “ingeschakled” in
> hetzelfde bestand? Nou ja, laten we het er maar op houden dat in 9 alles
> weer ok is. ;)

Dit soort opmerkingen helpen natuurlijk ook niet. meld dan wat er fout is zodat het snel verbeterd kan worden!

in ieder geval heb ik wat aanpassingen gedaan zodat het vanavond mee gaat in de beta voor 9

http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/b7eaf0338e9b
Een klein foutje in de accesskey van het nieuw toegevoegde contextmenuitem 'Element inspecteren'. In rij 199 van browser/chrome/browser/browser.dtd mag inspectContextMenu.accesskey veranderd worden in iets anders. Nu verschijnt de Q achter het item. Wellicht dat een E werkt?
(In reply to Gert-Paul van der Beek from comment #32)
> Een klein foutje in de accesskey van het nieuw toegevoegde contextmenuitem
> 'Element inspecteren'. In rij 199 van browser/chrome/browser/browser.dtd mag
> inspectContextMenu.accesskey veranderd worden in iets anders. Nu verschijnt
> de Q achter het item. Wellicht dat een E werkt?

Geen foutje maar het volgen van de en-US versie bug 587134. 

"One side-effect was that the new context menu item access key is 'Q', since every letter in 'Inspect Element' was already used."

Ik ga even kijken of in de nl versie wel nog een andere letter beschikbaar is.
This was mentioned in the MozillaNL mailing list:
https://www.mozdev.org/mailman/private/mozillanl/2011-December/001520.html
"
Als je in Aurora de menu-optie Help - Over Aurora (F) aanklikt, krijg je
het 'Over Aurora' scherm met daarin onder meer de tekst "Het stuurd
automatisch testinformatie'. Stuurd zou hier stuurt moeten zijn.

De tekst zit in browser/chrome/browser/aboutDialog.dtd en de entity heet
warningDesc.telemetry
Als het goed is, is deze tekst alleen zichtbaar in Aurora en Nightly.
"

Thanks to Marco van den Hout for noticing.
Tim: als je toch bezig bent: in newaddon.dtd moet “in gedachte” natuurlijk “in gedachten” zijn. (En title, restartButton en restartMessage deugen hier eigenlijk ook niet ;) )

Kan er eigenlijk alweer in Aurora worden gewerkt?
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #34)
> This was mentioned in the MozillaNL mailing list:
> https://www.mozdev.org/mailman/private/mozillanl/2011-December/001520.html
> "
> Als je in Aurora de menu-optie Help - Over Aurora (F) aanklikt, krijg je
> het 'Over Aurora' scherm met daarin onder meer de tekst "Het stuurd
> automatisch testinformatie'. Stuurd zou hier stuurt moeten zijn.
> 
> De tekst zit in browser/chrome/browser/aboutDialog.dtd en de entity heet
> warningDesc.telemetry
> Als het goed is, is deze tekst alleen zichtbaar in Aurora en Nightly.
> "
> 
> Thanks to Marco van den Hout for noticing.

is al verbeterd, http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/a9a1ed2f11maar bedankt voor het melden hier.
(In reply to Ton from comment #35)
> Tim: als je toch bezig bent: in newaddon.dtd moet “in gedachte” natuurlijk
> “in gedachten” zijn. (En title, restartButton en restartMessage deugen hier
> eigenlijk ook niet ;) )


nogmaals geef een suggestie hoe jij denkt dat het moet, hier kan ik niet zo veel mee. maar ik kijk er naar als ik weer thuis ben

> 
> Kan er eigenlijk alweer in Aurora worden gewerkt?

ja dat kan weer (zie de topic verandering van het irc kanaal)
(In reply to Tim Maks van den Broek from comment #37)
> 
> nogmaals geef een suggestie hoe jij denkt dat het moet, hier kan ik niet zo
> veel mee. maar ik kijk er naar als ik weer thuis ben

Ik had het zo maar gebracht, omdat je deze fouten zelf inmiddels ook zou moeten herkennen. ;) Maar vooruit:

title=Add-on installeren
restartButton=&brandShortName; herstarten
restartMessage=U moet &brandShortName; herstarten om het installeren van deze add-on te voltooien.

Verder zou ik het “het”, “informatie” en “beter worden” zoals in de eerdergenoemde zin vermijden, dus zoiets gebruiken als “Er worden automatisch testgegevens naar &vendorShortName; teruggestuurd om te helpen bij het verbeteren van &brandShortName;.”.
(In reply to Ton from comment #38)
> (In reply to Tim Maks van den Broek from comment #37)
> > 
> > nogmaals geef een suggestie hoe jij denkt dat het moet, hier kan ik niet zo
> > veel mee. maar ik kijk er naar als ik weer thuis ben
> 
> Ik had het zo maar gebracht, omdat je deze fouten zelf inmiddels ook zou
> moeten herkennen. ;) Maar vooruit:
> 
Of ik ze wel of niet herken doet er niet toe, als ik ze verander en het is nog niet naar jou zin blijf we bezig. het is gewoon handiger als je hier meld wat jou verbeteringen zijn :)

ik zal je suggesties meenemen, bedankt
ontvangen via mail van Tim van der Meij:

Wellicht is dan beter om de
zin als volgt te formuleren: 'Nightly is experimenteel en kan onstabiel
zijn. Het stuurt automatisch testinformatie terug naar Mozilla zodat
Nightly verbeterd kan worden.' Die zin lijkt me iets beter dan de huidige
zin

en

Overigens wil ik wel even zeggen dat de vertaling voor de rest echt erg
goed is. Ik kom maar zelden applicaties tegen die zó goed vertaald zijn
(hoe vaak ik samengestelde woorden al niet fout heb zien gaan...), waarvoor
dus mijn complimenten!
Attached patch Controle t/m 2012-01-30 (obsolete) — Splinter Review
Op de valreep, of erna: controle van de mappen browser, dom, netwerk, security, services en toolkit.

/devtools is alleen van wat foutjes ontdaan, maar niet volledig. Ik vraag me overigens nog steeds af of we die moeten vertalen, en of deze voor de release niet beter Engels kan blijven zolang e.e.a. nog niet volledig is.

Wat te doen met patches voor mobiel, of valt dat ook onder deze bug?
Hoi, ik had afgelopen weekend l10n gecontroleerd voor mobile Aurora (op de hoofdzaken), het zag er goed uit. Ik heb er screenshots van gemaakt:
http://people.mozilla.com/~mwargers/l10n/11.0a2/nl/
(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #42)
> Hoi, ik had afgelopen weekend l10n gecontroleerd voor mobile Aurora (op de
> hoofdzaken), het zag er goed uit. Ik heb er screenshots van gemaakt:
> http://people.mozilla.com/~mwargers/l10n/11.0a2/nl/

Dank
(In reply to Ton from comment #41)
> Created attachment 592915 [details] [diff] [review]
> Controle t/m 2012-01-30
> 
> Op de valreep, of erna: controle van de mappen browser, dom, netwerk,
> security, services en toolkit.
> 
Dank, net te laat voor mij maar ik pas het wel op 2 repo's toe :-)

> /devtools is alleen van wat foutjes ontdaan, maar niet volledig. Ik vraag me
> overigens nog steeds af of we die moeten vertalen, en of deze voor de
> release niet beter Engels kan blijven zolang e.e.a. nog niet volledig is.
> 
Zie de discussie in de bug (bug 710582) daarover, eindconclusie is vertalen en jij hebt aangeboden om het te doen. jammer dat je niet genoeg tijd hebt voor het vertalen van devtools terwijl je hebt aangeboden om het te doen. Als ik dat eerder had geweten had ik iemand anders gevraagd.

> Wat te doen met patches voor mobiel, of valt dat ook onder deze bug?

Ik een een aurora bug voor mobiel aangemaakt (bug 722704)
(In reply to Tim Maks van den Broek from comment #44)
> (In reply to Ton from comment #41)
> > Created attachment 592915 [details] [diff] [review]
> > Controle t/m 2012-01-30
> > 
> > Op de valreep, of erna: controle van de mappen browser, dom, netwerk,
> > security, services en toolkit.
> > 
> Dank, net te laat voor mij maar ik pas het wel op 2 repo's toe :-)

vanwege Fosdem is de L10N repro eerder omgezet door pike, anders was je precies op tijd geweest.
patch is toegepast, morgen merge ik central in aurora vanaf dan is er een stringfreeze for en-US in aurora (als het geod is ;-0 ) en kan er gewerkt worden aan firefox 13. 6 weken vanaf vandaag is de merge naar beta. verbeteringen graag iets eerder aanbieden.
Comment on attachment 592915 [details] [diff] [review]
Controle t/m 2012-01-30

(In reply to Tim Maks van den Broek from comment #46)
> kan er gewerkt
> worden aan firefox 13.

ik bedoel natuurlijk firefox 12 (firefos 13 is in de nightly-kanaal waar natuurlijk ook aan gewerkt mag worden. hier is alleen nog geen stringfreeze)
Attachment #592915 - Attachment is obsolete: true
Aurora is nu geheel bijgewerkt. er komen geen nieuwe strings meer bij en er kan dus gewerkt worden het verbeteren van de huidige strings. de wissel naar beta is op 13 maart, graag en pach iets eerder aanbieden zodat er nog rustifg naar gekeken kan worden voordat het beta wordt.
Het viel mij zonet op dat het het javascriptkladblok (browser/devtools/scratchpad.dtd) enkele accesskeys niet goed staan in aurora. Het betreft Zoeken(F)/Opnieuw zoeken(G)/Spring naar regel(J).

Ik zou willen voorstellen dat dit respectievelijk Z/E/S wordt.

Het is een beetje kort dag voordat we naar de beta gaan, sorry daarvoor. Maar had tot vandaag nooit het kladblok gebruikt. En anders wordt het maar de volgende release.
(In reply to Gert-Paul van der Beek from comment #49)
> Het viel mij zonet op dat het het javascriptkladblok
> (browser/devtools/scratchpad.dtd) enkele accesskeys niet goed staan in
> aurora. Het betreft Zoeken(F)/Opnieuw zoeken(G)/Spring naar regel(J).
> 
> Ik zou willen voorstellen dat dit respectievelijk Z/E/S wordt.
> 
> Het is een beetje kort dag voordat we naar de beta gaan, sorry daarvoor.
> Maar had tot vandaag nooit het kladblok gebruikt. En anders wordt het maar
> de volgende release.

Dank, er waren acceskeys en (command)keys omgewisseld

http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/051f84562f27
Attached patch Controle t/m 12-03-2012 (obsolete) — Splinter Review
Comment on attachment 605304 [details] [diff] [review]
Controle t/m 12-03-2012

Bedankt!

toegepast: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/fd6bf3671973
Attachment #605304 - Attachment is obsolete: true
(In reply to Tim Maks van den Broek from comment #50)
> (In reply to Gert-Paul van der Beek from comment #49)
> > Het viel mij zonet op dat het het javascriptkladblok
> > (browser/devtools/scratchpad.dtd) enkele accesskeys niet goed staan in
> > aurora. Het betreft Zoeken(F)/Opnieuw zoeken(G)/Spring naar regel(J).
> > 
> > Ik zou willen voorstellen dat dit respectievelijk Z/E/S wordt.
> > 
> > Het is een beetje kort dag voordat we naar de beta gaan, sorry daarvoor.
> > Maar had tot vandaag nooit het kladblok gebruikt. En anders wordt het maar
> > de volgende release.
> 
> Dank, er waren acceskeys en (command)keys omgewisseld
> 
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/051f84562f27

Volgens mij is hetzelfde gebeurd in browser/devtools/sourceeditor.dtd. Daar mogen de accesskey en sneltoets ook omgewisseld worden.
(In reply to Gert-Paul van der Beek from comment #53)

> 
> Volgens mij is hetzelfde gebeurd in browser/devtools/sourceeditor.dtd. Daar
> mogen de accesskey en sneltoets ook omgewisseld worden.

juist: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/a83e1f7947fe
Attached patch Controle t/m 22-04 (obsolete) — Splinter Review
Opmerking: er zijn hierin enkele strings in gclicommand.properties hersteld die (per ongeluk?) door de patch van Martijn waren aangepast na de vorige controle. Vriendelijk verzoek hierop te letten en/of dit te bespreken als het opzet was.
Comment on attachment 617305 [details] [diff] [review]
Controle t/m 22-04

toegepast, dank
Attachment #617305 - Attachment is obsolete: true
Attached patch Controle t/m 04-06 (obsolete) — Splinter Review
Comment on attachment 630061 [details] [diff] [review]
Controle t/m 04-06

Toegepast op beta (de overgang was een dag vervroegt). mooie verbeteringen, dank
Attachment #630061 - Attachment is obsolete: true
Attached patch Controle t/m 15-07 (obsolete) — Splinter Review
Opmerkingen: er zit 1 wijziging in waarvan ik vrij zeker ben dat die geen probleem is, namelijk die van ‘gratis’ naar ‘vrije’ (…opensourcesoftware). Het moge duidelijk zijn dat dit de gewenste term is, i.t.t. het tot nu toe gehanteerde en zelfs bediscussieerde ‘gratis’. Voor mail en suite kan/moet deze uiteraard nog volgen.

Verder zit (voor het gemak?) ook de wijziging van de op dit moment 3 nog niet gewijzigde entity’s voor browser.dtd erin. Er ontbreken nog wel wat juiste licentieteksten, maar dat kan nog in een volgende actie. Alleen bij de nagelopen bestanden zouden ze in orde moeten zijn.
(In reply to Ton from comment #59)
 
> Verder zit (voor het gemak?) ook de wijziging van de op dit moment 3 nog
> niet gewijzigde entity’s voor browser.dtd erin. Er ontbreken nog wel wat
> juiste licentieteksten, maar dat kan nog in een volgende actie. Alleen bij
> de nagelopen bestanden zouden ze in orde moeten zijn.

via IRC had ik ook gevraagd om de licentieteksten niet aan te passen dus dit is ok
Comment on attachment 642430 [details] [diff] [review]
Controle t/m 15-07

Toegepast, bedankt weer voor de controle. 

Nogmaals het verzoek om het een week eerder te doen. vandaag is de dag dat alles naar beta gaat, nu ben ik toevallig vrij en kan ik het nog toepassen.
Attachment #642430 - Attachment is obsolete: true
Attached patch Patch voor csp.properties (obsolete) — Splinter Review
Comment on attachment 646985 [details] [diff] [review]
Patch voor csp.properties

met een vertraging vanwege mijn vakantie (zonder internet) dank voor de vertaling. toegepast.
Attachment #646985 - Attachment is obsolete: true
Attached patch Controle t/m 26-08 (obsolete) — Splinter Review
Ja ik weet het, weer wat laat, sorry.
Comment on attachment 655417 [details] [diff] [review]
Controle t/m 26-08

toegepast, dank
Attachment #655417 - Attachment is obsolete: true
Attached patch Controle t/m 07-10 (obsolete) — Splinter Review
Reminders:
- Nooit ‘u heeft’ gebruiken
- ‘worden’ achteraan vermijden
- kofschip / spatiegebruik
Comment on attachment 668923 [details] [diff] [review]
Controle t/m 07-10

toegepast, zal je opmerkingen proberen te onthouden :-)
Attachment #668923 - Attachment is obsolete: true
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/9e41bae38c3e
> -<!ENTITY styleeditor.accesskey        "i">
> +<!ENTITY styleeditor.accesskey        "S">

Dan zou ik ook de I voor inspecteren gebruiken…
daar heb ik aan gedacht maar niet gedaan. bij de andere zijn de engelse keys niet bruikbaar maar bij deze wel. ik twijfelde nogal, nu jij er ovrr begint zal ik het ook vervangen.
(In reply to Ton from comment #68)
> > http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/9e41bae38c3e
> > -<!ENTITY styleeditor.accesskey        "i">
> > +<!ENTITY styleeditor.accesskey        "S">
> 
> Dan zou ik ook de I voor inspecteren gebruiken…

Done: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/c9d3d27c47e3
Attached patch Controle t/m 06-01 (obsolete) — Splinter Review
Attached patch Controle Fx20a t/m 04-02 (obsolete) — Splinter Review
N.B. De vertaling van ‘deprecated’ lijkt hierin niet consistent, maar is wel beter en kan later in een aparte patch nog elders worden gelijkgetrokken.
(In reply to Ton from comment #73)
> Created attachment 709868 [details] [diff] [review]
> Controle Fx20a t/m 04-02
> 
> N.B. De vertaling van ‘deprecated’ lijkt hierin niet consistent, maar is wel
> beter en kan later in een aparte patch nog elders worden gelijkgetrokken.

-<!ENTITY abouthealth.intro.title "Wat is &brandShortName;-gezondheidsrapport?">
+<!ENTITY abouthealth.intro.title "Wat is het &brandShortName;-statusrapport?">

veel betere vertaling, bedankt!
Comment on attachment 709868 [details] [diff] [review]
Controle Fx20a t/m 04-02

toegepast: committed changeset 2635:17667164bb4c
Attachment #709868 - Attachment is obsolete: true
Attached patch andere term voor deprecated (obsolete) — Splinter Review
(In reply to Ton from comment #73)
> 
> N.B. De vertaling van ‘deprecated’ lijkt hierin niet consistent, maar is wel
> beter en kan later in een aparte patch nog elders worden gelijkgetrokken.

Bij deze.
wikipedia: Uitfasering (Engels: deprecation) verwijst in computerprogramma's en in HTML naar bepaalde mogelijkheden (functionaliteit) in software of scripttaal die op termijn verwijderd kunnen worden en dus vermeden moeten worden.

ik weet niet of afgeschaft de lading dan beter dekt...
Wat hierboven staat klopt. Zoek je puur naar een vertaling voor de term zelf, dan kom je vaak uit op ‘verouderd’ of ‘afgekeurd’. De schijn wordt echter gewekt dat iets dan nog wel bruikbaar is, maar de is kans vrij groot dat het daarnaast ook helemaal niet meer werkt. Waarschijnlijk is dat de reden dat MS vrijwel overal de term ‘afgeschaft’ gebruikt (of heel soms ‘wordt niet meer ondersteund’), wat voor mij de doorslag gaf. Zie ook Interglot en (vooral) de Microsoft Glossary.
Een beetje jammer dat de patch voor deprecated niet meer op tijd is toegepast voor Aurora en dus Bèta. Overigens vind ik de tekst “wordt niet meer ondersteund” daarin ook prima (doch liever niet), als de strekking van het niet meer mogen gebruiken maar duidelijk is en alle voorvallen consistent zijn, in tegenstelling tot nu.

Verder schijnt er sinds FX11 of 12 nog een tekstfoutje te zitten in syncUnlink.label (‘gegegevens’). Dit geldt ook voor SeaMonkey.

Wellicht dat beide zaken nog in Bèta kunnen worden meegenomen.
rustig, let een beetje op je toon. ik heb het ook wel eens druk en de patch wad mij geheel ontschoten.
Ik beschuldig je nergens van en met mijn toon hierboven is denk ik niets mis, maar als je erop staat zal ik voortaan een extra paar fluwelen handschoenen aantrekken voor het typen. ;)
(In reply to Ton from comment #81)
> Ik beschuldig je nergens van en met mijn toon hierboven is denk ik niets
> mis, maar als je erop staat zal ik voortaan een extra paar fluwelen
> handschoenen aantrekken voor het typen. ;)

natuurlijk is er niets met jou (aan jou ligt het nooit), het ligt geheel aan mij.
(In reply to Ton from comment #79)
Overigens vind ik de tekst “wordt niet
> meer ondersteund” daarin ook prima (doch liever niet), als de strekking van
> het niet meer mogen gebruiken maar duidelijk is en alle voorvallen
> consistent zijn, in tegenstelling tot nu.

mijn voorkeur gaat uit naar 'niet meer ondersteund' waarom vind je het prima maar doch liever niet?
(In reply to Ton from comment #79)

> Verder schijnt er sinds FX11 of 12 nog een tekstfoutje te zitten in
> syncUnlink.label (‘gegegevens’). Dit geldt ook voor SeaMonkey.


verbeterd in changeset 3259
(In reply to Tim Maks van den Broek from comment #83)
> (In reply to Ton from comment #79)
> Overigens vind ik de tekst “wordt niet
> > meer ondersteund” daarin ook prima (doch liever niet), als  de strekking van
> > het niet meer mogen gebruiken maar duidelijk is en alle voorvallen
> > consistent zijn, in tegenstelling tot nu.
> 
> mijn voorkeur gaat uit naar 'niet meer ondersteund' waarom vind je het prima
> maar doch liever niet?

Morgen ga ik hieraan werken (hoop ik), aangezien er geen reactie gekomen is op mijn vraag ga ik voor 'niet meer ondersteund'
(In reply to Tim Maks van den Broek from comment #83)
> (In reply to Ton from comment #79)
> Overigens vind ik de tekst “wordt niet
> > meer ondersteund” daarin ook prima (doch liever niet), als de strekking van
> > het niet meer mogen gebruiken maar duidelijk is en alle voorvallen
> > consistent zijn, in tegenstelling tot nu.
> 
> mijn voorkeur gaat uit naar 'niet meer ondersteund' waarom vind je het prima
> maar doch liever niet?

Omdat afgeschaft in de eerste instantie de meer voorkomende term zou zijn (zie ook http://www.microsoft.com/Language/en-US/Search.aspx?sString=deprecated&langID=nl-nl), al is het ook weer contextafhankelijk. Niet meer ondersteund is wellicht net zo duidelijk, en afgeschaft natuurlijk ook niet helemaal verboden. Kijk maar waar je wat beter vindt staan.
ok bedankt voor de input
Comment on attachment 710325 [details] [diff] [review]
andere term voor deprecated

toegepast, als transvision de verandering verwerkt heeft zal ik onderzoeken of het nu overal goed is (gelijk vertaald is).
Attachment #710325 - Attachment is obsolete: true
Attached patch FX23a - dubbele key en typo (obsolete) — Splinter Review
Wijziging van een key en een typo n.a.v. bug 762572#c42. Ik heb nu wel voor de b gekozen i.p.v. de daarin voorgestelde a, omdat dit dan dezelfde key is als die in het contextmenu op een pagina (Paginabron bekijken). Maar met de a kan ik ook leven (bv. omdat de overige keys in het menu allemaal de eerste letter zijn en de 7e positie hierdoor wat opvalt/afwijkt).
Comment on attachment 763101 [details] [diff] [review]
FX23a - dubbele key en typo

Toegepast http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/71e611ed123c

ps 'b' vind ik ook beter als 'a' kan men nog onthouden als de b van bron
Attachment #763101 - Attachment is obsolete: true
Momenteel wordt services vertaald in firefox als diensten, maar op de ondersteunigspagina gekoppeld aan 'meer info' staat Firefox-services. Volgens mij moet een van de twee aangepast worden....
Nav mijn opmerking in bug 762572:
In dom/chrome/dom/dom.properties
- GetPreventDefaultWarning=Gebruik van getPreventDefault() wordt niet meer ondersteund. ebruik in plaats daarvan defaultPrevented.
+ GetPreventDefaultWarning=Gebruik van getPreventDefault() wordt niet meer ondersteund. Gebruik in plaats daarvan defaultPrevented.

Verder merkte ik in Aurora dat er een accesskey verkeerd staat in de nieuwe zoekbalk bij de term '(Hoofdlettergevoelig)'. Dit is nu een C en ik denk dat een H wel een ok optie is:
toolkit/chrome/global/finddialog.dtd
- <!ENTITY caseSensitiveCheckbox.accesskey "o">
+ <!ENTITY caseSensitiveCheckbox.accesskey "H">
Zo te zien gaat het hier om toolkit/chrome/global/findbar.dtd#15, die een o moet worden; deze verhuist gewoon mee (ik meen dat finddialog niet meer wordt gebruikt). En de H is geen optie (Help…).
(In reply to Tim Maks van den Broek [:mad_maks] from comment #91)
> Momenteel wordt services vertaald in firefox als diensten, maar op de
> ondersteunigspagina gekoppeld aan 'meer info' staat Firefox-services.
> Volgens mij moet een van de twee aangepast worden....

Beetje late reactie hierop wellicht, maar alsnog: deze vraag is ooit eerder gesteld (door Wim meen ik), maar naar mijn mening wordt services in de eerste plaats vertaald als services (ik denk in zo’n 90% van de gevallen), hoewel dit uiteraard afhankelijk is van de context. MS bijvoorbeeld gebruikt voor zover ik weet nergens ‘Diensten’ in producten, en het lijkt me in dit geval ook niet de bedoeling dat zonder meer in Firefox te doen als dat niet op zijn plaatst is.

In softwarevertalingen gaat het in de meeste gevallen om (software)processen of andere integraties. Het klakkeloos hanteren van ‘diensten’ is meer iets voor vertalers en/of taalpuristen met een voorkeur voor Nederlandse termen in het algemeen, en wellicht ook Vlamingen (no offense). In Firefox hebben we het niet over een buslijn die buiten dienst is. Gaat men naar een telecomservicezaak voor reparatie van een telefoon, dan gebruikt men ook het woord dienst niet. ’s Lands grootste (of 1 na grootste) internetprovider met een X in de naam spreekt op de homepage over hun services. Bedrijven hebben vaak een afdeling Service, wat niets met diensten te maken heeft, noch als het gaat om een stukje extra service dat geboden wordt. Hierin blijkt eveneens een verschil in betekenis.

Ik moet zeggen dat de rillingen over mijn rug liepen toen ik ‘Diensten’ in een releaseversie zag verschijnen. Hoe dan ook, het is niet voor niets dat Sumo ‘Services’ hanteert, en gaat het hier om een integratie van software van externe partijen (zoals FB), niet zozeer over ‘diensten’ daarvan. Wat mij betreft mag/moet dit dus zo snel mogen worden aangepast.

Overigens wil ik me een dezer dagen weer gaan bezighouden met controleren (en als je het kan waarderen, het aanvullen) van Aurora-versies van FX en Fennec, waarna je misschien ook wat correcties kunt toepassen op de huidige bètaversies ervan (het gaat me wat te ver om dat ook te doen), want er is wel meer niet pluis. Kun je laten weten of dat OK is, of dat je eerst zelf nog de boel wilt afronden?
als het je de rillingen bezorgde waarom heb je dat niet eerder gemeld? ik stel de vraag niet voor niks en ben het er helemaal mee eens om het te veranderen. 

maar ik ben wel van mening dat sumo een verlengde is van firefox en dat de helpagina's de gebruikte termen van firefox moeten volgen. als degene die de vertaling maakt voor sumo een term niet juist vind moet het eerst aangepast worden in het product. 

ov er het bijwerken van aurora, graag! ik ben best druk momenteel en kan alle hulp gebruiken.
Attached patch Aanvulling FX 26a t/m vandaag (obsolete) — Splinter Review
Overige bestanden zijn nog niet gecontroleerd, bevat wel correcties uit comment 92. Devtools volgt in eigen bug.
Comment on attachment 822746 [details] [diff] [review]
Aanvulling FX 26a t/m vandaag

toegepast, bedankt.
Ik weet niet of de overige mappen nog gaan lukken voor deze release, maar het is een begin.
Typo…
Attachment #8344346 - Attachment is obsolete: true
Comment on attachment 8344347 [details] [diff] [review]
Controle /browser van 04-02 t/m vandaag v2

toegepast
Attachment #8344347 - Attachment is obsolete: true
Attachment #822746 - Attachment is obsolete: true
Comment on attachment 8344936 [details] [diff] [review]
Controle overige bestanden van 04-02 t/m vandaag

toegepast op aurora en beta, graag een (uiterlijk) een paar dagen eerder voor de merge day aanleveren zodat ik deze niet op de verschillende kanalen moet toepassen/mergen.
Attachment #8344936 - Attachment is obsolete: true
Op het moment vertalen we scrolling als schuiven: http://transvision.mozfr.org/?repo=central&sourcelocale=en-US&locale=nl&search_type=strings&recherche=scrolling maar is het beter (en duidelijker) om scrollen te gebruiken? zie ook http://www.woorden.org/woord/scrollen
Mee eens, we gebruiken ook al andere termen met sroll erin. Zoek dan uiteraard wel naar ‘scroll’.
Is er hulp nodig bij het bijwerken?
(In reply to Ton from comment #106)
> Is er hulp nodig bij het bijwerken?

als je de tijd heb, graag
Attached patch Aanvulling fx 28a (obsolete) — Splinter Review
Bevat ook 2 nog niet eerder vertaalde strings in dom.properties en een wijziging in access key voor Openen in nieuw privévenster vanwege soms optredend conflict.
Comment on attachment 8351443 [details] [diff] [review]
Aanvulling fx 28a

toegepast.
Attachment #8351443 - Attachment is obsolete: true
Attached patch Controle fx28a (obsolete) — Splinter Review
Bevat ook de momenteel ontbrekende string in browser.dtd.
Comment on attachment 8358993 [details] [diff] [review]
Controle fx28a

toegepast
Attachment #8358993 - Attachment is obsolete: true
Attached patch Afgelopen x dagen (obsolete) — Splinter Review
Voortkomend uit https://bugzilla.mozilla.org/show_bug.cgi?id=722704#c46 en nog niet verwerkt. Komt ook nog in deze vorm voor in mail en suite.
(In reply to Ton from comment #112)
> Created attachment 8362106 [details] [diff] [review]
> Afgelopen x dagen
> 
> Voortkomend uit https://bugzilla.mozilla.org/show_bug.cgi?id=722704#c46 en
> nog niet verwerkt. Komt ook nog in deze vorm voor in mail en suite.

in mail en suite?
Zie mailViewLastFiveDays (of zoek op "last days"). Weet alleen even niet waar dit zich bevindt en/of of het nog wordt gebruikt. Kijk maar even…
ah ik zocht naar de letterlijke string uit je patch, ik heb het gevonden en ga het aanpassen.
Hulp nodig?
Grazg, ben erg druk met andere mozilla activiteiten (en privé) momenteel
Attached patch Update fx 29 (obsolete) — Splinter Review
Moet access keys nog controleren op conflicten. Bevat ook enkele kleinigheidjes (pop-ups, punt weg, ‘vertellen’ en Mac-afsluititem), en html.properties was blijkbaar nog niet geheel vertaald.
Enkele onjuiste variabelen in /security, evenals in devtools. Bevat ook Find -> Zoeken (goed gezien) en enkele access keys die wat meer voor de hand liggen en uniform worden.
Comment on attachment 8388066 [details] [diff] [review]
Enkele variabelen, Zoeken en access keys

Toegepast http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/26d7a21bb480
Attachment #8388066 - Attachment is obsolete: true
Attached patch Fx: quota-> quotum (obsolete) — Splinter Review
Dito patch voor Fennec bevatte per abuis de gevallen in /services, die natuurlijk hier hadden gemoeten.
Attached patch …wachtwoordne en meer… (obsolete) — Splinter Review
Als de & en wordt in Fennec, moet dat natuurlijk ook in dezelfde zin in Fx.
Comment on attachment 8392575 [details] [diff] [review]
…wachtwoordne en meer…

toegepast rev 53e3da059fc0
Attachment #8392575 - Attachment is obsolete: true
Misschien wat laat maar dan hopelijk voor de bèta: het viel me op dat sommige menu-items in het Australis-menu niet al te mooi of onnodig worden afgebroken. Het gaat dan om “Pagina op- slaan”, “Bestand ope- nen”, maar ook “Nieuw tab- blad”, “Nieuw ven -ster”, “Tabbladgroe- pen” en “Synchroni- seren”. Deze wijzigingen zorgen voor netjesc.q. niet afbreken, dus Pagina opslaan, Bestand openen, Nieuw tabblad (onder elkaar) en Tabblad- groepen en Syncho- niseren.

Graag nog wel even testen in zo veel mogelijk systemen en uiteraard met alle verplaatsbare opties, zoals door flod gevraagd.
Attached patch Controle fx30a (obsolete) — Splinter Review
Ik kwam toch weer het een en ander aan foutjes tegen die we het liefst niet in Fx30 zouden zien. Graag toepassen voordat Aurora verder wordt bijgewerkt (net als de vorige patch), en als het kan voor een nieuwe sign-off of 30 bèta.

Bevat ook accesskeywijziging van d->M in bladwijzers sorteren, zal er al even in.
Comment on attachment 8414724 [details] [diff] [review]
fx30: hyphenation edits in Australis-menu

Dank voor de patch, was inderdaad nog een openstaande controle

http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4b9aa2ecb974
Attachment #8414724 - Attachment is obsolete: true
Comment on attachment 8417050 [details] [diff] [review]
Controle fx30a

Blijkbaar is de appstrings.properties van mobile in webapprt tercht gekomen ipv die van dom :-(

Dank, patch toegepast http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/352e98da3f88
Attachment #8417050 - Attachment is obsolete: true
Worden de ontbrekende strings voor 31 nog toegevoegd? Zo ja, wanneer en door wie? Zo nee, is er hulp nodig en wat is dan de deadline voor het aanleveren van patches?
Hoi Ton, dank voor de verbeteringen. Kun jij de rest nog afmaken vandaag?
Dit vond ik nog in een e-mail van Jeff:
Thank you all for your great work with Firefox 29 and 30. Here's an
outline of what is currently in Aurora this cycle (31) and what we
accomplished together last cycle:

This cycle (28 April - 9 June)

Key dates include:
     - Beta sign offs must be completed before 2 June.
     - Aurora sign offs must be completed before 9 June.
     - Firefox 30 releases 10 June. 

Vandaag dus de laatste mogelijkheid voor sign-off, of laten we een en ander doorsijpelen naar beta?
Hey WIm, OK ik ben ermee bezig (in patchvorm), maar wie gaat de sign-off en merge etc. doen? Is Tim met vakantie en doe jij dat? Wat doorsijpelen betreft: het geeft wel kans om e.e.a. na te lopen, maar dat is niet aan mij denk ik… ;)
Attached patch Aanvulling Fx31a (obsolete) — Splinter Review
Ontbrekende strings en bestand, geen verdere controle.
Omdat er nu op de laatste 2 versies geen controle is uitgevoerd en er daarom helaas weer wat foutjes in de releaseversies zijn geslopen, wilde ik dat uiteraard alsnog doen. Dit geldt voor zowel Fx als Fennec. Kunnen we daarom afspreken wanneer bijwerken voor 33 gereed is?

Verder dit: ik ga niet meer de moeite nemen om achteraf (dus voor de bèta) de boel te corrigeren; het is dus voor Aurora, of niet, en als ik het niet meer red, helaas. Omdat ik vind dat de kwaliteit van de producten ook niet (meer?) van mijn nakijkwerk afhankelijk moet zijn, zou ik het daarom erg waarderen als er voortaan na voltooiing van het bijwerken van elke versie door Tim Maks in de betreffende bugs om een controle wordt gevraagd, en dat er dus niet meer stilletjes wordt aangenomen dat e.e.a. wel in orde zal zijn. Is dit mogelijk?
Firefox 33 is klaar voor controle
Bestanden buiten de map 'browser' maar die wel voor firefox gebruikt worden (zoals toolkit, dom) gaan nu via bug 1064769
Status: NEW → ASSIGNED
Mappen die momenteel alleen voor firefox gebruikt worden zoals webapprt gaan wel via deze bug
Firefox 34 is klaar voor controle, sorry dat het zo laat is.
Attached patch Controle FX34a (obsolete) — Splinter Review
Misschien wat puntjes die het overdenken waard zijn:

- Wat als we “Naar map op hoger niveau gaan” vervangen door het wat meer standaard “Naar bovenliggende map”?
- Is er bezwaar als overal (op enkele uitzonderingen na) Klaar wordt vervangen door Gereed?
- “Certificate authority” is vertaald als “Certificatieautoriteit”, o.a. om Netscape-historische redenen, en ik zag dit ook nog terug in Android 2.3.x. “Certificeringsinstantie” is hiervoor een wat meer gangbare term. Enige ideeën hierover?
Firefox 35 is klaar voor controle

een punt voor discussie wellicht:
in Loop vertaal ik conversation met gesprek maar in chat etc word dat vertaald met conversatie. In dit geval denk ik dat gesprek beter past........


(In reply to Ton from comment #144)
> Misschien wat puntjes die het overdenken waard zijn:
> 
> - Wat als we “Naar map op hoger niveau gaan” vervangen door het wat meer
> standaard “Naar bovenliggende map”?
> - Is er bezwaar als overal (op enkele uitzonderingen na) Klaar wordt
> vervangen door Gereed?
> - “Certificate authority” is vertaald als “Certificatieautoriteit”, o.a. om
> Netscape-historische redenen, en ik zag dit ook nog terug in Android 2.3.x.
> “Certificeringsinstantie” is hiervoor een wat meer gangbare term. Enige
> ideeën hierover?


Met alle drie de punten kan ik het vinden.
(In reply to Tim Maks van den Broek [:mad_maks] from comment #145)
> (In reply to Ton from comment #144)
> > - “Certificate authority” is vertaald als “Certificatieautoriteit”, o.a. om
> > Netscape-historische redenen, en ik zag dit ook nog terug in Android 2.3.x.
> > “Certificeringsinstantie” is hiervoor een wat meer gangbare term. Enige
> > ideeën hierover?
> 
> 
> Met alle drie de punten kan ik het vinden.

Behalve dan dat veel rootcertificaten eindigen met de afkorting CA. Als je certificatieautoriteit aan houdt, dan kan je die CA daar naar herleiden...
Naar aanleiding van een tweet deze week zou ik de vertaling van "link" weer eens willen oprakelen.
Wat is destijds de reden geweest om er "koppeling" van te maken?
"Link" is inmiddels zo ingeburgerd en het staat ook als zodanig omschreven in de Van Dale.
https://twitter.com/KFouq/status/527395855146704896
Er was nog een verandering in aurora dus een controle patch graag vanuit rev ffa36221987d

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #146)

> Behalve dan dat veel rootcertificaten eindigen met de afkorting CA. Als je
> certificatieautoriteit aan houdt, dan kan je die CA daar naar herleiden...

de engelse afkorting is geen reden om een bepaalde vertaling te gebruiken, lijkt mij.

(In reply to Wim from comment #147)
> Naar aanleiding van een tweet deze week zou ik de vertaling van "link" weer
> eens willen oprakelen.
> Wat is destijds de reden geweest om er "koppeling" van te maken?
> "Link" is inmiddels zo ingeburgerd en het staat ook als zodanig omschreven
> in de Van Dale.
> https://twitter.com/KFouq/status/527395855146704896

ik heb even teruggezocht en ik vermoed dat het een netscape vertaling was (in firefox 0.x kom ik het al tegen)

persoonlijk heb ik er niks op tegen om koppeling door link te vervangen maar als ik in de vandale kijk kunnen beide http://www.vandale.nl/opzoeken?pattern=koppeling&lang=nn#.VFvaGflyg_s en http://www.vandale.nl/opzoeken?pattern=link&lang=nn#.VFvaXvlyg_s
Momenteel vertalen we "report site" als "website rapporteren" http://transvision.mozfr.org/?recherche=report&repo=central&sourcelocale=en-US&locale=nl&search_type=strings

Maar bij het vertalen van een nieuw bestand voor fennec was het eerste wat in mij opkwam de vertaling "Website melden"

Misschien een idee om "rapporteren" te vervangen voor "melden"? (scheel ook weer een paar karakters wat voor mobiel fijn is)
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #146)
> (In reply to Tim Maks van den Broek [:mad_maks] from comment #145)
> > (In reply to Ton from comment #144)
> > > - “Certificate authority” is vertaald als “Certificatieautoriteit”, o.a. om
> > > Netscape-historische redenen, en ik zag dit ook nog terug in Android 2.3.x.
> > > “Certificeringsinstantie” is hiervoor een wat meer gangbare term. Enige
> > > ideeën hierover?
> > 
> > 
> > Met alle drie de punten kan ik het vinden.
> 
> Behalve dan dat veel rootcertificaten eindigen met de afkorting CA. Als je
> certificatieautoriteit aan houdt, dan kan je die CA daar naar herleiden...

Ok, de wijziging naar Gereed lijkt me dan geen probleem, evenals die naar Bovenliggende map.

Wat CA betreft: de herkenning bij de afkorting CA is inderdaad wel handig en was meen ik ook een reden om in elk geval autoriteit aan te houden bij de eerste vertaling. Het ging me nu om de gangbaarheid van vandaag, waarbij er mogelijkheden zijn als:
1) certificaatautoriteit
2) certificatieautoriteit 
3) certificeringsautoriteit
4) certificeringsinstantie
… en misschien nog meer (~organisatie, ~instelling etc.).

Wikipedia en Apple hebben een voorkeur voor 1, MS voor 4. Geval 2 zie ik niet zo vaak in zoekresultaten, ook niet i.c.m. een merk of organisatie. Hoewel het voor de hand ligt om (alleen) certificering boven certificatie te verkiezen vanwege de hogere gangbaarheid en het feit dat het om “het uitgeven van” certificaten gaat, lijkt 3 in de totale term niet zinvol en geen voorkeur te hebben boven 1 of 2. Het verschil tussen 1 en 2 is wel bijzonder; 2 lijkt om dezelfde reden voor de hand te liggen, maar komt veel minder voor dan 1. Overigens is er ook in het Engels wat onduidlijkheid over de vraag of CA nu staat voor ‘certificate authority’ of ‘certification authority’, maar qua zoekreultaten wint de eerste het toch, ook op de wiki.

In de huidige tree komt certificaatautoriteit één keer voor (wellicht per ongeluk) en in de overige gevallen certificatieautoriteit. Het lijkt me voorlopig het beste om overal (1) te gaan gebruiken, wat dus inhoudt dat op 1 na overal certificatieautoriteit naar certificaatautorieit gaat. Bezwaren of betere ideeën?
> (In reply to Wim from comment #147)
> > Naar aanleiding van een tweet deze week zou ik de vertaling van "link" weer
> > eens willen oprakelen.
> > Wat is destijds de reden geweest om er "koppeling" van te maken?
> > "Link" is inmiddels zo ingeburgerd en het staat ook als zodanig omschreven
> > in de Van Dale.
> > https://twitter.com/KFouq/status/527395855146704896
> 
> ik heb even teruggezocht en ik vermoed dat het een netscape vertaling was
> (in firefox 0.x kom ik het al tegen)

Volgens mij waren er destijds heel veel bezwaren tegen link, alleen al vanwege links of rechts, en is de voor zichzelf respecterende browsers gangbare term toch (snel)koppeling. Zie ook de reactie van de tweet onder die van Mozilla_NL.

> persoonlijk heb ik er niks op tegen om koppeling door link te vervangen maar
> als ik in de vandale kijk kunnen beide
> http://www.vandale.nl/opzoeken?pattern=koppeling&lang=nn#.VFvaGflyg_s en
> http://www.vandale.nl/opzoeken?pattern=link&lang=nn#.VFvaXvlyg_s

Voor mij is het turbo- of spreektaal en dus uit den boze. Let er ook op dat VD het in de 2e eh … koppeling :) als “mogelijkheid om” omschrijft, dus niet als de koppeling zelf.
Mee eens, we laten het zo.
(In reply to Tim Maks van den Broek [:mad_maks] from comment #149)
> Momenteel vertalen we "report site" als "website rapporteren"
> http://transvision.mozfr.org/?recherche=report&repo=central&sourcelocale=en-
> US&locale=nl&search_type=strings
> 
> Maar bij het vertalen van een nieuw bestand voor fennec was het eerste wat
> in mij opkwam de vertaling "Website melden"
> 
> Misschien een idee om "rapporteren" te vervangen voor "melden"? (scheel ook
> weer een paar karakters wat voor mobiel fijn is)

In principe eens, maar het is misschien een beetje contextafhankelijk. Is er sprake van bv. misbruik (gedrag of actie), dan kun je dit melden. Gaat het om een ding (in dit geval een website of gebruiker), dan is dit meer iets van “aangeven” (van een persoon o.i.d.) en rapporteren wellicht beter. Vergelijk het met bv. inbraak; de inbraak kun je melden, de inbreker niet. Kan het even niet beter omschrijven … Let ook op de consistentie. Als je bv. een webvervalsing rapporteert en deze daarna als een gerapporteerde webvervalsing wordt omschreven, zou het dan bij het melden van een webvervalsing een gemelde webvervalsing worden?

Karakters komen overigens alleen in landen als Japan voor, wij gebruiken tekens, om maar even de woorden van Laurens te gebruiken. ;)
(In reply to Ton from comment #151)

> Zie ook de reactie van de tweet onder die van Mozilla_NL.


ik interpreteer die reactie als; vertaal link niet en laat het ook link zijn in de nl versie ipv koppeling...... 

Conclusie van deze "discussie": we blijven link vertalen met koppeling.

(In reply to Ton from comment #153)
> In principe eens, maar het is misschien een beetje contextafhankelijk. Is er
> sprake van bv. misbruik (gedrag of actie), dan kun je dit melden. Gaat het
> om een ding (in dit geval een website of gebruiker), dan is dit meer iets
> van “aangeven” (van een persoon o.i.d.) en rapporteren wellicht beter.
> Vergelijk het met bv. inbraak; de inbraak kun je melden, de inbreker niet.
> Kan het even niet beter omschrijven … Let ook op de consistentie. Als je bv.
> een webvervalsing rapporteert en deze daarna als een gerapporteerde
> webvervalsing wordt omschreven, zou het dan bij het melden van een
> webvervalsing een gemelde webvervalsing worden?

Natuurlijk is het context afhankelijk, al was het alleen al dat report ook rapport kan betekenen :-)

Ik zal eens een patch maken voor Fx en die aan deze bug hangen, kunnen we die bespreken.
(In reply to Tim Maks van den Broek [:mad_maks] from comment #154)
> 
> ik interpreteer die reactie als; vertaal link niet en laat het ook link zijn
> in de nl versie ipv koppeling...... 
> 
Inderdaad, ik zag later dat die van dezelfde persoon was en hij het dus zo bedoelde.

> Ik zal eens een patch maken voor Fx en die aan deze bug hangen, kunnen we
> die bespreken.

Ok, enig idee wanneer? Dit i.v.m. komende controle en mogelijk ‘botsen’.

Iets anders: we gebruiken de kreet "welke wordt beheerd door" in Fx en Fennec, wat denk ik niet helemaal juist is. Bezwaar als we dit op beide plekken vervangen door "Deze website wordt beheerd door", zoals in het commentaar dat erboven staat?
(In reply to Ton from comment #155)

> 
> Ok, enig idee wanneer? Dit i.v.m. komende controle en mogelijk ‘botsen’.
> 
Weet ik nog niet maar de pach kan als discussie stuk dienen en ik maak me wel druk over de merge (het botsen)

> Iets anders: we gebruiken de kreet "welke wordt beheerd door" in Fx en
> Fennec, wat denk ik niet helemaal juist is. Bezwaar als we dit op beide
> plekken vervangen door "Deze website wordt beheerd door", zoals in het
> commentaar dat erboven staat?

Ik zie geen bezwaar.
Oproep aan iedereen die deze bug volgt:

Als er hier (of in een van de andere NL vertaalbugs) een voorstel wordt gedaan om een vertaling te wijzigen is het prettig als je reageert, ook als je het er mee eens bent.
Dan weten we wat het draagvlak is van een aanpassing en kunnen we hier naar terug verwijzen als er later eventueel weer een discussie over de aanpassing ontstaat.

Alvast bedankt!!
Attached patch Controle fx35a (obsolete) — Splinter Review
Access keys (voor delen) zijn gecontroleerd.
Comment on attachment 8521421 [details] [diff] [review]
Controle fx35a

-<!ENTITY cmd.unblock.label                "Niet blokkeren">
-<!ENTITY cmd.unblock.accesskey            "N">
+<!ENTITY cmd.unblock.label                "Deblokkeren">
+<!ENTITY cmd.unblock.accesskey            "o">

Ik vraag me af, deze string wordt zichtbaar als Fx iets wilt blokkeren en is dus nog niet geblokkeerd. Deblokkeren doe je bij iets wat al geblokkeerd is..., je wilt voorkomen dat het geblokkeerd word.
Worden ze dan niet ergens allebei tegelijk zichtbaar? Moeilijk te zeggen waarschijnlijk, omdat de string nog niet in de UI zichtbaar is, maar vermoedelijk komt het (ook) in een contextmenu. ‘Niet blokkeren’ lijkt me strikt genomen in elk geval niet juist, omdat je daarmee de suggestie wekt dat dit een eenmalige of uitsluitend eerste actie is die niet meer ongedaan kan worden gemaakt, en dus de mogelijkheid tot het opheffen van een bestaande blokkering niet zichtbaar is. Het lijkt me dat dat ook zichtbaar gaat worden, anders had Engels hier waarschijnlijk ook ‘Do not block’ gebruikt, bv. bij een eerste actie/vraag. Ik zie er trouwens van komen dat er nog wel een extra string bijkomt n.a.v. gebruik om meerdere plaatsen.
Het huidige Unblock wordt doorgaans vertaald als Blokkering opheffen, en vanwege de lengte (contextmenu/knop) heb ik (voorlopig dus) voor deblokkeren gekozen. Mocht lengte geen probeem zijn, dan zou ik voor het eerste kiezen, maar dat blijkt pas als de functie zichtbaar wordt.
Attached patch Key voor Selectie delen e.a. (obsolete) — Splinter Review
Evenals een andere dubbele, komma’s in getallen en het in comment 155 genoemde ‘Deze website…’.
Attached patch Kleinigheidjes in loop.prop (obsolete) — Splinter Review
Firefox 36 is klaar voor controle
Attached patch Controle fx36a (obsolete) — Splinter Review
Ook wat aanpassingen in woordvolgorde, eerde aangehaalde zaken en onjuistheden m.b.t privévensters.

Reminders:
- in de regel infinitief gebruiken (eerder opgemerkt, moet duidelijk zijn)
- gebruik van ‘worden’ achteraan vermijden (eerder opgemerkt)
- alleen punten bij opdrachten / zinnen / teksten richting gebruiker en dus nooit bij knopteksten, opties en tooltips
Comment on attachment 8535553 [details] [diff] [review]
Controle fx36a

toegepast, http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/d06866fea8b3

en dank voor je opmerkingen, zal er op letten :-)
Attachment #8535553 - Attachment is obsolete: true
Gisteren toegepaste patch zorgt voor foutmelding door (opzettelijk) 2 x gebruik van variabele in 1 zin. Patch corrigeert dit, werkt 6 nieuwe strings van vandaag bij en neemt enkele gevallen van Klaar mee.
Vergeten klemtoon toegevoegd en meer logische access keys.

Tim: let je op flods posting over de strings voor 35 bèta en de daarvoor benodigde acties? Laat het even weten als je hiervoor een patch zou willen zien.
Attachment #8536041 - Attachment is obsolete: true
(In reply to Ton from comment #170)
> Created attachment 8536155 [details] [diff] [review]
> Fix voor foutmelding, paar nieuwe strings en nits v2
> 
> Vergeten klemtoon toegevoegd en meer logische access keys.
Ik vond het al zo vreemd dat ik die variabele 2de variabele had gemist in die zin, maar vertrouwde erop dat het klopte....

> 
> Tim: let je op flods posting over de strings voor 35 bèta en de daarvoor
> benodigde acties? Laat het even weten als je hiervoor een patch zou willen
> zien.

Het heeft mijn aandacht en staat voor morgen op het programma. de string bestaan ondertussen in aurora dus het is een kwestie van porten en de setting aanpassen.
(In reply to Tim Maks van den Broek [:mad_maks] from comment #171)
> (In reply to Ton from comment #170)
> > 
> Ik vond het al zo vreemd dat ik die variabele 2de variabele had gemist in
> die zin, maar vertrouwde erop dat het klopte....

Hmja, ik had het gedaan om ‘het’ (voor het in te vullen product) te vermijden; wellicht zou het werken maar de foutmelding is natuurlijk niet wenselijk. Ik dacht dat het ook ergens in TB gebeurde, maar dat is dan waarschijnlijk met een extra $brandShortName; geweest, of ik vergis me. Nou ja, zo kan het ook.

Iets anders: zijn de bestanden in /B2G nog nodig en zo ja, vallen patches hiervoor onder de gezamelijke bug?
Comment on attachment 8536155 [details] [diff] [review]
Fix voor foutmelding, paar nieuwe strings en nits v2

toegepast; http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/97ac96de469b
Attachment #8536155 - Attachment is obsolete: true
(In reply to Ton from comment #170)
 
> Tim: let je op flods posting over de strings voor 35 bèta en de daarvoor
> benodigde acties? Laat het even weten als je hiervoor een patch zou willen
> zien.

http://hg.mozilla.org/releases/l10n/mozilla-beta/nl/rev/fb20700bbb92
(In reply to Ton from comment #172)
 
> Iets anders: zijn de bestanden in /B2G nog nodig en zo ja, vallen patches
> hiervoor onder de gezamelijke bug?

Geen idee, lijkt me dat ze onder jouw suppervisie vallen als beheerder van fxos
Attached patch Controle fx37a (obsolete) — Splinter Review
Plus enkele comflicterende keys en kleinigheidjes.
Attached patch Betere keys voor Hello (obsolete) — Splinter Review
Enkele conflicterende of onhandige keys voor Hello.
Ik zie in browser, mail en suite dat permissions de ene keer vertaald als machtigingen en de andere keer als toestemmingen (en soms als rechten). Moeten we daar niet overal hetzelfde van maken? Waarbij machtigingen mijn voorkeur heeft, want toestemming vind ik niet echt iets meervouderigs...
Firefox 38 (Aurora) is klaar voor controle behoudens de 2 overbodige keys.
Attached patch Controle fx38a (obsolete) — Splinter Review
Patch toegepast, bedankt!
Attached patch fx38.0a2.patch (obsolete) — Splinter Review
Verbetering van een aantal typo's in Firefox 38.0a2
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #182)
> Created attachment 8582311 [details] [diff] [review]
> fx38.0a2.patch
> 
> Verbetering van een aantal typo's in Firefox 38.0a2

De eerste 2 behoren bij Devtools; wijzigingen daarin verlopen via bug 762572. Wel goed gezien; de eerste typo had ik gezien, de tweede niet (maar is verklaarbaar. ;) Deze zijn verwerkt. Kun je de patch obsolete maken en de laatste 2 opnieuw aanbieden?
Heb de overige 2 al toegepast.
Attachment #8582311 - Attachment is obsolete: true
-printing_not_ready=Warning: PDF is niet volledig geladen om af te drukken.
+printing_not_ready=Waarschuwing: PDF is niet volledig geladen om af te drukken.

Net te laat… Ik had deze wel gezien maar blijkbaar niet in de patch opgenomen. Ik zou hier het volgende van hebben gemaakt: 
Waarschuwing: de PDF is niet volledig geladen voor afdrukken.

Reden: vermijden van om-constructie en http://transvision.mozfr.org/?recherche=for+printing&repo=aurora&sourcelocale=en-US&locale=nl&search_type=strings_entities
Toegepast: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/7d8609f8bf6a

LET OP: Sign-off moet voor 30 maart, dus nog slechts enkele dagen voor wijzigingen.
Dezelfde wijzigingen als in TB (Latijns en schriftsystemen), met een correctie op iets wat ook al een tijdje over het hoofd is gezien. Daarbij zal Thai ook Thais moet worden om dezelfde reden als Latijn vs. Latijns (taal vs. schrift). Dat geldt ook voor TB; in de fallback-entity bij FF was dit wel in orde. Ook de genoemde pdf-string hierboven meegenomen.
Attachment #8567507 - Attachment is obsolete: true
Attachment #8571987 - Attachment is obsolete: true
Attachment #8581296 - Attachment is obsolete: true
Comment on attachment 8583846 [details] [diff] [review]
Correcties in fonts.dtd en pdf-string

Toegepast zonder PDF, want die had ik net al gedaan.
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/baa1fe515994
Attachment #8583846 - Attachment is obsolete: true
Ik zag het, had de patch juist net opnieuw gemaakt om die mee te nemen en zag je comment niet.

Er zijn vandaag 4 nieuwe strings bijgekomen, testen ervan gaat helaas nog niet. Laat maar even weten of een patch wordt gewaardeerd. En is het een idee om je naam in je Mercurial-programma aan te passen zodat die zichtbaar is in de logs i.p.v. het begin van je ssh-string?
Heb dit er van gemaakt:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/18b0a12b105f
Nu met mijn naam erbij, dank voor het melden.
Ik zou het doen zoals in de patch, voornamelijk omdat de zinnen anders wel erg Engels zijn en eigenlijk eigenlijk niet kloppen of lekker lopen. Pleasant is niet altijd plezierig, nog vormt een pleonasme, anywhere is niet altijd overal en contextafhankelijk, we hanteren geen hoofdletters waar en-US dat wel en zelfs ongedocumenteerd/afwijkend voor producten t.o.v. webpagina’s en de rest wel doet bij vermeende ‘proper nouns’, en aanhalingstekens maken we uitsluitend en al sinds 2005 ‘curly’ (zie bug 305315 en het vertaalwoordenboek). Let ook altijd op commentaarregels / oorspronkelijke changesets, ga niet alleen af op het dashboard.

Ook betere keys en een resterende wisseling in woordvolgorde zoals die al elders is aangepast (alleen nog niet in mail).
Comment on attachment 8585052 [details] [diff] [review]
Recente strings voor leeslijst e.a.

Toegpast:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/272cded2c919

Ik beschouw deze als laatste en zal hierop de sign off doen.
Attachment #8585052 - Attachment is obsolete: true
Comment on attachment 8585197 [details] [diff] [review]
Dingetjes n.a.v. controle TB, browser

Toegepast:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/09c237422594
Attachment #8585197 - Attachment is obsolete: true
Ik zit even met een dingetje dat wellicht ook nog in bèta 38 kan worden verbeterd: ‘Typebediening’ (Type controls) voor de lezerweergave bevalt me niet, andere locales lijken er ook wat moeite mee te hebben. Wat te denken van Lettertype-instellingen? Komt een beetje overeen met wat de en it doen.

Als er nog andere dingetjes zijn die in bèta 38 niet juist zijn (ik heb er al enkele gevonden), dan graag even laten weten.
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/2a0bccd36634

Bijgewerkt, controle is welkom. Alleen bij newtab.xxxxButton zijn twee puntjes verwijderd, voor de rest niets gewijzigd.
Even een issue: een van de dingen die nog niet juist zijn in 38 bèta en 39a is Tracking Protection. Dit wilde ik aanvankelijk omzetten van het huidige ‘Volgbescherming’ naar ‘Bescherming tegen volgen’ zoals dat in Sumo al wordt gebruikt. Het ligt echter voor de hand om hiervoor Traceerbeveiliging te gaan gebruiken, maar dat roept 2 bedenkingen op:

1) MS gebruikt deze term ook, zijnde een functie die op de DNT-pagina wordt genoemd als vervanger in IE voor Do Not Track / Niet volgen in FF. Nu is het punt dat op die pagina wordt gemeld dat daarin gebruik wordt gemaakt van tracking protection lists, m.a.w. het zou dan om exact dezelfde functie gaan als TP in FF. Zowel de tijd van invoer van die functie in IE (8?) als enkele webpagina’s wijzen er echter op dat het daarin niet meer is dan het meesturen van een header zoals bij DNT. Ik heb dus nog geen zekerheid maar vermoed dat, ook omdat er nog andere onjuistheden in de DNT-pagina zouden zijn, de info daarop over IE weleens onjuist zou kunnen zijn, of wellicht heeft men in IE inmiddels iets omgezet, of uitgebreid en beide functies samen ondergebracht zonder naamswijziging. Kort gezegd: het zou kunnen dat wat IE Traceerbeveiliging noemt, DNT is, óf DNT én TP. Hanteren van het ‘echte’ Traceerbeveiliging voor Tracking protection in FF zou dus verwarring kunnen geven bij gebruikers. Het lijkt me minder interessant, want we staan vrij in de eigen keuze en als het nu eenmaal juister is om dat zo te doen, dan zij het zo.

2) Als we Traceerbeveiliging gebruiken en dus ook de term ‘traceren’, rijst wellicht de vraag waarom dan ‘volgen’ voor ‘tracking’ in Niet volgen, hoewel dat wat vergezocht lijkt en een overdreven geval van consistentie zou zijn omdat de context wat anders is, en het verschil tussen beide functies juist beter wordt benadrukt, eigenlijk net zoals bij 1). Het gaat dus wat ver om dat ook om te bouwen, maar er moet dan bij komende vertalingen wel goed op het verschil in functies worden gelet als het verwarring zou kunnen geven.

Meningen/bezwaren?
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/b3d6b26dbe93

Het volgende aangepast:
- aanhalingstekens en klemtonen
- keys voor about: en Browserwerkset
- ‘opzetten’ en puntjes verwijderd bij feedoptie
- teksten bij sessieherstel aangepast (heeft nog wel iets nodig)
- Volgbescherming -> Bescherming tegen volgen
- deze -> het in compatibiliteitsmelding
- en x meer -> en nog x
- enkele strings in installer-bestand
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/1114a0c6e3c2

Bijgewerkt voor 40a, controle welkom.

Meegenomen: niet-vertaalde string in bookmarks.inc, gemiste changeset in *.css-bestanden en deze wat verder aangepast. (Bovengeoemde typo in devtools was al eerder verwerkt.)
newtab.suggested.tag vertaal je met VOORGESTELD. Dat klopt wel, maar ik zou AANBEVOLEN gebruiken (hoewel dat recommended in het Engels is)
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #201)
> newtab.suggested.tag vertaal je met VOORGESTELD. Dat klopt wel, maar ik zou
> AANBEVOLEN gebruiken (hoewel dat recommended in het Engels is)

Als iets een suggestie is (zoals hier), is dat slechts een voorstel. Iets wat aanbevolen wordt (doet me denken aan Featured) is toch iets anders, wat inderdaad meer met recommendations te maken heeft (dit is meer de discussie over de term ‘featured’ op bv. Marketplace). Daarom denk ik dat Aanbevolen zeker net juist is voor deze getoonde voorstellen. Sterker nog: gebruikers zouden hier misschien minder blij mee zijn dan Suggesties, omdat sommigen de suggesties al als spam beschouwen, laat staan als ze door Mozilla aanbevelingen worden genoemd.

Nu het toch over de New Tab page gaat: kennelijk is niemand opgevallen dat New Tab page en verwante zaken eigenlijk niet juist zijn vertaald. Ik zou hier graag reacties over zien voordat ik er zelf mee aan de gang ga (wat wellicht wat impact heeft).
(In reply to Ton from comment #202)
> Nu het toch over de New Tab page gaat: kennelijk is niemand opgevallen dat
> New Tab page en verwante zaken eigenlijk niet juist zijn vertaald. Ik zou
> hier graag reacties over zien voordat ik er zelf mee aan de gang ga (wat
> wellicht wat impact heeft).

Verwerkt in http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/67348d34e58c .
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/file/default/browser/chrome/browser/preferences/sync.dtd#l92
apapraten > apparaten
Enige typo die ik kon vonden, nu door naar devtools :) .
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4baceb6b1d51#l9.29
gemaild of ge-e-maild??
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4baceb6b1d51#l10.11
Bij Safari staat "Uit" en bij Edge staat "uit". Beide kleine letters denk ik, dus "uit".

Wederom bedankt voor de inzet!
(In reply to Wim from comment #211)
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4baceb6b1d51#l9.29
> gemaild of ge-e-maild??

Heb hier met opzet gemaild gebruikt, ge-e-maild is wel juist maar ziet er wat minder aantrekkelijk uit. Om dezelfde reden eerder bijvoorbeeld ook bevestigingsmail i.p.v. bevestigings-e-mail, weet even niet meer waar. Maar als je hier per se ge-e-maild wilt zien…?

> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4baceb6b1d51#l10.11
> Bij Safari staat "Uit" en bij Edge staat "uit". Beide kleine letters denk
> ik, dus "uit".

Beide groot lijkt consistenter aangezien Uit al even werd gebruikt, volgens mij ook in het verleden elders, maar het kan als een zin worden gezien, dus OK.

Ik neem dit mee in de komende nits.
Ik vraag me af of voor "Refresh Firefox" het huidige "Firefox vernieuwen" wel gepast is. Dit is voortgekomen uit het gebruik van "vernieuwen" voor "refresh" bij pagina’s, maar kan wellicht verwarrend werken (in de zin van opnieuw of een nieuwere versie installeren). Op het net heb ik wat verschijnselen van "opfrissen" hiervoor gezien; misschien niet echt een woord uit de vertaalwereld, maar wel beter dekkend. Ideeën over aanpassen hiervan, wellicht zelfs naar nog een andere term?
In de diverse tweets gebruik ik vaak "opfrisbeurt" dat wel tot de verbeelding spreekt en "opfrissen" komt wel het dichtste bij de werkelijkheid. 
Op http://synoniemen.net/index.php?zoekterm=vernieuwen kwam ik nog "moderniseren" tegen, maar dat is meer een populistische uitdrukking.
"Opschonen" komt ook wel in de buurt.
"Verbeteren" kan ook, is wat vaag.
Vergeten te melden:
Update browser 45a: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/fffefb87fadb

Update browser 46a: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/556c4a282c79
Aanpassing van certificaatautoriteit (comment 150) is toegepast op gezamenlijke mappen.
Eerder bijgewerkt voor 47a (en vergeten hier te melden):
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/6f6403c08e45

Bijgewerkt voor 48a, controle welkom:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/622bd667b435
N.a.v. comment 214: zullen we ‘Opfrissen’ dan maar invoeren?

Verder denken zowel Onno als ik dat de tijd rijp is om ‘programmatuur’ toch echt te vervangen door ‘software’. Zie hiervoor een eerdere discussie in bug 326915 van alweer 10 jaar geleden.

Meningen/bezwaren?
Lijkt me prima.
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/aab0d646855c

Wat aanpassingen n.a.v. consistentiecontrole.

Gewijzigde zaken (ook in andere onderdelen/bugs) omvatten:
- wat eliminaties van ‘succesvol’
- zoeken in -> zoeken op pagina (lijkt gebruikelijker)
- alle soorten -> alle typen (verbindingen)
- ‘(en)’ uit privacybeleid etc. verwijderd
- access key, kleine foutjes en nits
See Also: → 1358894
Update browser 51a: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/299c64828040
Update browser 52a: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/2960955a06a2
Update browser 53a: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/d04cd94d632d
Update browser 54a: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/d0cd50971c21

Vanaf 19 april 2017 werken we in central, zie bug 1358894, dus deze bug wordt gesloten.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: