Closed Bug 658869 Opened 9 years ago Closed 3 years ago

[nl] mozilla-aurora/nl thunderbird

Categories

(Mozilla Localizations :: nl / Dutch, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mad_maks, Assigned: nONoNonO)

References

(Depends on 1 open bug)

Details

Attachments

(26 obsolete files)

Bug voor de verbeteringen in het Miramar-kanaal

http://hg.mozilla.org/releases/l10n-miramar/nl
"Thunderbird 3.3, we're setting the target date at 7 June."
Blocks: 456252
Bug voor de verbeteringen in het Aurora-kanaal

http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl
Summary: [nl] mozilla-miramar/nl thunderbird → [nl] mozilla-aurora/nl thunderbird
Comment on attachment 548061 [details] [diff] [review]
Correcties en enkele aanpassingen d.d. 24-7

Verkeerde bug.
Attachment #548061 - Attachment is obsolete: true
Attached patch Controle t/m 26-04 (obsolete) — Splinter Review
Comment on attachment 618936 [details] [diff] [review]
Controle t/m 26-04

Toegepast, dank.
Attachment #618936 - Attachment is obsolete: true
Ik zag op mozbrowser weer een klacht/vraag over de woordvolgorde van de reply-header. Aangezien de vele bugs die hiervoor bestaan afhankelijk zijn gemaakt van bug 107884 en deze ondanks enige recente voortgang toch nog wel even onopgelost zal blijven, lijkt het me verstandig om maar eens voor een tijdelijke oplossing te kiezen.

In een van de afhankelijke bugs, om precies te zijn bug 666912, wordt verwezen naar bug 485251, waarin sv-SE (tot nu toe als enige) gebruikmaakt van een aanpassing in all-l10n.js voor zowel het standaardtype (2 naar 3) als de gewenste spatie. Tim, kun jij eens kijken of dat voor nl ook mogelijk is?

Ik weet niet meer precies of dat al eens is gebeurd, maar het moet toch mogelijk zijn, zou je zeggen. Wel vraag ik me af of dit bij bestaande profielen ook gaat werken, of alleen bij nieuwe. Zo ja, dan hoeft alleen "Op" te worden gewijzigd in "op" (in …_ondate). Daarmee blijft bij eventueel handmatig omschakelen tussen type 3 en 1 via de config-editor in beide gevallen sprake van een juiste woordvolgorde.

http://www.mozbrowser.nl/forum/viewtopic.php?f=11&t=21992 (actuele topic)
http://www.mozbrowser.nl/forum/viewtopic.php?f=11&t=19429 (ouder topic)
https://bugzilla.mozilla.org/show_bug.cgi?id=485251#c5 (tijdelijke fix)
(In reply to comment #7)

> In een van de afhankelijke bugs, om precies te zijn bug 666912, wordt…

Bedoel natuurlijk bug 666923
Attached patch Fix voor reply-header (obsolete) — Splinter Review
Toch maar even de tijd genomen voor een dito fix als die welke sv-SE gebruikt voor het hierboven genoemde probleem, in afwachting van een betere oplossing.

Het standaard headertype gaat hiermee van 2 naar 3 (dus geen 1, omdat het huidige standaardtype 2 ook de datum weergeeft), de komma wordt een spatie en ‘op’ krijgt een kleine letter. Als het goed is vormt dit “Piet schreef op 24-02-2013 17:00:”.

Aan Tim de keus om dit toe te passen in Aurora, waarna we dit voor alle platformen kunnen testen. Omdat ik vooral benieuwd ben naar het effect bij bestaande installaties/profielen, heb ik de betrokkenen van de Zweedse bug gemaild met die vraag. We kunnen dus het antwoord daarop afwachten, hoewel zelf testen hier ook al antwoord op kan geven. De werking van de wijzigingen is wel in orde, maar het gaat met name om de verwerking van all-l10n.js.
Omdat TB sinds 13a niet meer is gecontroleerd en het daarvoor hoog tijd wordt: Tim, zie je kans om TB bij het bijwerken van Aurora voorrang te geven op de andere producten, zodat er wat meer tijd is om te controleren, en dan een seintje te geven als het zo ver is?
ok, goed idee.
Antwoord van Hasse:

“As I remember it, and some quick tests confirms this, setting the prefs in composeMsgs.properties and all-l10n.js will fix the problem for most existing profiles too. But for users who have already changed one of these prefs themselves, all bets are off. There is just nothing you can do to ensure a correct string in that situation.”

Dat laatste lijkt me logisch, omdat aangepaste voorkeuren van een gebruiker voorrang krijgen. De boel herstellen naar de standaardwaarden (waartoe all-l10n.js dan ook wordt gerekend) zou dit dan volgens mij weer goed moeten zetten. De moeite waard dus.
(In reply to Ton from comment #10)
> Omdat TB sinds 13a niet meer is gecontroleerd en het daarvoor hoog tijd
> wordt: Tim, zie je kans om TB bij het bijwerken van Aurora voorrang te geven
> op de andere producten, zodat er wat meer tijd is om te controleren, en dan
> een seintje te geven als het zo ver is?

Ga je gang :-)
Bedankt. :)

Wanneer wilde je het bovenstaande proberen, liever voor of na de controle? (Niet dat het veel uitmaakt denk ik…)
Maak niet echt uit, ik zal het wel zo toepassen dan hebben we de tijd om te testen.
Comment on attachment 717629 [details] [diff] [review]
Fix voor reply-header

Toegepast changeset 2716
Attachment #717629 - Attachment is obsolete: true
Zo te zien werkt het in Windows goed; na een update gaan de twee nieuwe standaardinstellingen keurig mee, en reeds gewijzigde instellingen hiervan blijven zoals ze zijn. Hoe is het in Linux / op Mac?
(In reply to Ton from comment #17)
> Zo te zien werkt het in Windows goed; na een update gaan de twee nieuwe

Met ‘update’ bedoelde ik hier een update van een nightly, dus geen major (versie-)update. Des te beter, zou ik zeggen.

Inmiddels meer ervaringen?
(In reply to Ton from comment #17)
> Zo te zien werkt het in Windows goed; na een update gaan de twee nieuwe
> standaardinstellingen keurig mee, en reeds gewijzigde instellingen hiervan
> blijven zoals ze zijn. Hoe is het in Linux / op Mac?

Op Linux gaan de nieuwe instellingen ook goed mee.
Attached patch Update t/m 27-10 (Tb26a) (obsolete) — Splinter Review
Nog geen controle van de rest (helaas).
Comment on attachment 823176 [details] [diff] [review]
Update t/m 27-10 (Tb26a)

toegepast, bedankt
Attachment #823176 - Attachment is obsolete: true
+pop3ServerBusy=De account %S wordt verwerkt. Wacht totdat de verwerking is voltooid om berichten te verkrijgen.

is het niet beter om 'de' weg te laten?
Welke 'de' precies, die in de tweede zin, omdat dat in het Engels ontbreekt? In dat geval zou ik 'de' behouden, staat net iets netter. Als het is vanwege "totdat de" (2 x achter elkaar een D-klank), dan zou ik er "tot de" van maken.

Wat denk je overigens over controleren van de rest? Eerst wachten tot je straks Aurora weer hebt bijgewerkt, of is er ruimte om aan 26 bèta te werken? (TB en/of FF)
nee, sorry dat ik niet duidelijker was. ik bedoelde de eerste 'de' voor account.

als je deze week met een controle patch komt kunnen we die nog toepassen op beta als het aan mij ligt.
Sterker, als er al een bepaald lidwoord voor "account" zou moeten komen, dan moet het (volgens mij althans) "het" zijn.
(In reply to Tim Maks van den Broek [:mad_maks] from comment #24)
> nee, sorry dat ik niet duidelijker was. ik bedoelde de eerste 'de' voor
> account.

Ah, vermoedde al zoiets, omdat je dat in SeaMonkey had weggelaten. Maar in dat geval: ik zie geen enkele reden waarom in deze zin geen lidwoord zou moeten staan of dat het moet worden weggelaten. Dit gebeurt immers overal als het er in de Engelse tekst ook staat, er is geen sprake van ruimtegebrek voor NL en het combineert ook niet met de rest van deze en de hele zin erna. Mocht je het willen doen vanwege twijfels van sommigen over de of het, dan is dat natuurlijk ook geen reden. Als er dan toch iets moet worden gewijzigd (doelend op verschillen in TB en SM), dan zou ik in beide gevallen beginnen met ‘De’, en eventueel ‘totdat’ naar ‘tot’ wijzigen.

(In reply to A.P. Veening from comment #25)
> Sterker, als er al een bepaald lidwoord voor "account" zou moeten komen, dan
> moet het (volgens mij althans) "het" zijn.

Absoluut niet, ‘account’ is en blijft in de eerste plaats een de-woord. Dit is eerder (in 2007) uitgebreid besproken en ik wil de discussie liever niet opnieuw starten. Misschien kun je beter even op https://lists.ubuntu.com/archives/ubuntu-l10n-nl/2011-February/000685.html kijken, waarin ook wordt verwezen naar een topic bij Mozbrowser.nl, en daarin een verwijzing naar bug 372370.
In afwachting van een antwoord hier had ik het weggelaten in SM zodat we de uitkomst maar op een plek hoeven aanpassen. Ik verander het in SM, bedankt voor de reactie.
(In reply to Ton from comment #26)

> (In reply to A.P. Veening from comment #25)
> > Sterker, als er al een bepaald lidwoord voor "account" zou moeten komen, dan
> > moet het (volgens mij althans) "het" zijn.
> 
> Absoluut niet, ‘account’ is en blijft in de eerste plaats een de-woord. Dit
> is eerder (in 2007) uitgebreid besproken en ik wil de discussie liever niet
> opnieuw starten. Misschien kun je beter even op
> https://lists.ubuntu.com/archives/ubuntu-l10n-nl/2011-February/000685.html
> kijken, waarin ook wordt verwezen naar een topic bij Mozbrowser.nl, en
> daarin een verwijzing naar bug 372370.

Mijn excuses, ik was niet op de hoogte van het bestaan van die hele discussie, mijn post was gebaseerd op mijn taalgevoel (welke heel redelijk ontwikkeld is als zoon van een lerares Nederlands en een leraar Duits). Ik zal echter de discussie niet weer oprakelen.
Het nalopen van de hele TB-bron (sinds 26-04-2012, dus…) gaat weer niet lukken, maar omdat een bepaalde tekst over instellingen voor de Lokale map nogal eens voor verwarring kan zorgen die regelmatig tot onbegrepen situaties en topics op o.a. Mozbrowser leidt, heb ik dat wel vast voor het betreffende bestand gedaan.
Comment on attachment 8344364 [details] [diff] [review]
Update prefs.properties 2013-12-08

toegepast
Attachment #8344364 - Attachment is obsolete: true
Attached patch Update TB28a (obsolete) — Splinter Review
Update voor TB28a t/m vandaag

Opmerkingen:
1) Hier en daar hanteren we nog steeds ‘niet-ingebedde’ (~ inhoud, bij ‘remote’) waar volgens mij kan worden volstaan met ‘externe’. Misschien kunnen we hier eens naar kijken / gedachten hierover?
2) Het ziet ernaar uit dat de term ‘Draft message’ nu voor het eerst voorbijkomt, waar eerder werd gesproken over ‘Message draft’. Vrij vertaald is dit het verschil tussen Conceptbericht en Berichtconcept, waar hetzelfde wordt bedoeld. Omdat zowel ‘draft message’ als ‘conceptbericht’ aanzienlijk hoger scoren in zoekresultaten en bepaalde grote softwareproducenten (tegenwoordig) alleen deze term lijken te hanteren, lijkt het me beter vanaf nu ook overal ‘conceptbericht’ te gebruiken. Dit moet dan ook nog nog elders gebeuren (3x), en wellicht is een patch voor en-US voor globaal aanpassen hiervan ook geen gek idee.
Comment on attachment 8348860 [details] [diff] [review]
Update TB28a

toegepast
Attachment #8348860 - Attachment is obsolete: true
(In reply to Ton from comment #31)
> Created attachment 8348860 [details] [diff] [review]
> Update TB28a
> 
> Update voor TB28a t/m vandaag
> 
> Opmerkingen:
> 1) Hier en daar hanteren we nog steeds ‘niet-ingebedde’ (~ inhoud, bij
> ‘remote’) waar volgens mij kan worden volstaan met ‘externe’. Misschien
> kunnen we hier eens naar kijken / gedachten hierover?
> 2) Het ziet ernaar uit dat de term ‘Draft message’ nu voor het eerst
> voorbijkomt, waar eerder werd gesproken over ‘Message draft’. Vrij vertaald
> is dit het verschil tussen Conceptbericht en Berichtconcept, waar hetzelfde
> wordt bedoeld. Omdat zowel ‘draft message’ als ‘conceptbericht’ aanzienlijk
> hoger scoren in zoekresultaten en bepaalde grote softwareproducenten
> (tegenwoordig) alleen deze term lijken te hanteren, lijkt het me beter vanaf
> nu ook overal ‘conceptbericht’ te gebruiken. Dit moet dan ook nog nog elders
> gebeuren (3x), en wellicht is een patch voor en-US voor globaal aanpassen
> hiervan ook geen gek idee.

Ik ben het helemaal met je eens. :-)
(In reply to Tim Maks van den Broek [:mad_maks] from comment #33)
> (In reply to Ton from comment #31)
> 
> Ik ben het helemaal met je eens. :-)

Nee maar. :) Naar ‘remote’ moeten we na een algehele controle maar eens kijken, hoewel dat uiteraard ook eerder kan.

Voor Conceptbericht is bug 951748 aangemaakt, waarin op dit moment nog geen ei is gelegd. Neemt niet weg dat we dat natuurlijk zelf kunnen bepalen, maar we kunnen ook even de uitkomst daarvan afwachten.
Zou het mogelijk zijn om aangeleverde patches zoals gebruikelijk aan de bug te hangen? Ik zie nu bijdragen uit het niets verschijnen. Niet dat het veel uitmaakt (er volgt nog wel een controle) en ik zou ze dan evengoed toegepast willen zien, maar het maakt het leveren van op- en aanmerkingen en uitleg over vertaalde termen en stijl etc. wat makkelijker.

Verder een vriendelijk doch dringend verzoek aan iedereen die bijdraagt om na het aanpassen van een bestand, dit nogmaals te controleren op onjuistheden (zowel op vertaling, typefouten als Mozilla-terminologie en als het kan stijl), en als de patch gemaakt is, die ook te controleren.

Morgen begin ik met een controle.
Nee dit zijn bijdragen van 'localizers in training' die door mij begeleid worden. De patches komen dus van mij en is de bijwerking van het geheel zoals altijd. Je kan je opmerkingen bij mij kwijt.
maar voor de zekerheid de stijlgids nog even onder de aandacht gebracht en een fout die in de laatste aanpassingen zat hersteld.
Attached patch TB29a, map /chat (obsolete) — Splinter Review
Begon als correctie van de regel met onjuiste variabelen (statusCommand), maar is feitelijk gelijktrekken van deze map met die van Instantbird geworden (op een kleine uitzondering na).
Attached patch TB29a, variabelen (obsolete) — Splinter Review
Comment on attachment 8389382 [details] [diff] [review]
TB29a, map /chat

Waarom de punt weg bij passwordPromptSaveCheckbox?

Is groepsgesprek niet een mooiere vertaling voor conference in deze context?

toegepast rev 95ca9a5dcd85
Attachment #8389382 - Attachment is obsolete: true
Comment on attachment 8389392 [details] [diff] [review]
TB29a, variabelen

toegepast, bedankt rev 337510bca170
Attachment #8389392 - Attachment is obsolete: true
(In reply to Tim Maks van den Broek [:mad_maks] from comment #40)
> Comment on attachment 8389382 [details] [diff] [review]
> TB29a, map /chat
> 
> Waarom de punt weg bij passwordPromptSaveCheckbox?

Omdat het een normale aanklikbare optie is en deze dus net als vergelijkbare opties (zoals in rememberPassword) dus de infinitiefvorm heeft en geen punt vereist, ook niet in het Engels. Punten zijn er alleen voor volledige zinnen en instructies die aan een gebruiker zijn gericht (dus gebiedende wijs). Ik zie trouwens net dat er in mobile\override\passwordmgr.properties ook een punt staat voor dezelfde optie, dus als je wilt kun je die ook verwijderen.

> Is groepsgesprek niet een mooiere vertaling voor conference in deze context?

Hmja, ik heb me bij Instantbird denk ik laten leiden door óf de gehanteerde term bij Yahoo Chat (of wat ik erover via Google kon vinden), dan wel de op het moment van introductie gehanteerde vertaling voor yahoo.properties, óf de algemene bij MS. Van de laatste weet ik dat Conference doorgaans Vergadering is, van Yahoo Chat kan ik het niet vaststellen, al lijkt de Yahoo-IM-client voor Blackberry ook over vergaderingen te spreken, vandaar. Maar helemaal zeker weten doe ik het niet, daarvoor zou iemand de officiële IM van Yahoo moeten installeren (als we die als leidend hanteren), waarvan ik twijfel of die überhaupt in het Nederlands bestaat.
N.a.v. http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/b71184e0f877 heb ik de daarin gewijzigde bestanden nagelopen, waaruit de volgende patch is gerold. Bevat ook quota->quotum, consistente H voor Herstarten en toevallig tegengekomen foutjes.

Reminders:
- Hele werkwoorden gebruiken (infinitief) in opties, eigenlijk bijna overal
- Voorzichtig omgaan met koppeltekens, maar wel gebruiken waar echt nodig
- Altijd even zoeken naar vergelijkbare strings in andere producten, of hetzelfde
- Werkwoorden in constructies als ‘Sort by name’ bij voorkeur vooraan i.p.v. de voorzetsels
In bovenstaande patch valt me eigenlijk nu pas op (addressbook.properties #71):

## %B is the month's localized name and %d is the day of the month [01-31].
## Don't go using %e here, since it breaks things on Windows!
## Separators (a space, dash, etc.) can be used
dateFormatMonthDay=%e %B

Ik maak hieruit op dat we net als in en-US %d moeten gebruiken. Tim, kun je dat nog aanpassen, evt. in de patch?

Nog een algemene reminder:
- werkwoord ‘worden’ bij voorkeur vooraan gebruiken (bv. "… dat wordt uitgevoerd")
Comment on attachment 8391925 [details] [diff] [review]
Correcties n.a.v. recente wijzigingen, quota->quotum e.a.

toegepast r ff70fcfea904
Attachment #8391925 - Attachment is obsolete: true
Ik zat enigszins verbaasd naar changeset http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/e4e24a104108te kijken… Hoe kan het dat fouten die er gisteren door een patch zijn uitgehaald op dezelfde dag in een bijwerkactie weer worden toegevoegd?
Target Milestone: --- → mozilla30
(In reply to Ton from comment #46)
> Ik zat enigszins verbaasd naar changeset
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/e4e24a104108te
> kijken… Hoe kan het dat fouten die er gisteren door een patch zijn
> uitgehaald op dezelfde dag in een bijwerkactie weer worden toegevoegd?

Als je goed kijkt naar de bestandsnamen zie je dat het restanten zijn van een merge (.dtd.orig) die niet goed ging. met deze bestanden wordt niks gedaan, ik ben ze vergeten te verwijderen voor de commit. En zelf als we ze laten zal de build ze niet gebruiken.
Onno,

Bedankt voor je patch, deze lijkt zorgvuldig of in elk geval goed te zijn gemaakt (al heb ik niet gecontroleerd op de volledigheid ervan).

Ik zie echter wel wat dingetjes die niet helemaal juist zijn. Hieronder een snelle opsomming (kopieer/plak) van allerlei strings waarin sprake is van onzorgvuldig / foutief spatiegebruik en het gebruik van de gebiedende wijs i.p.v. de infinitiefvorm (hele werkwoord)

<!ENTITY sourceEditField.label "Voeg LaTeX broncode in:">" (LaTeX-broncode invoegen)
<!ENTITY optionInline.label "Inline mode"> (Inlinemodus, spatiegebruik)
<!ENTITY optionDisplay.label "Weergave mode"> (Weergavemodus, spatiegebruik)
<!ENTITY autotagEnable.label         "Automatisch labels aanmaken van feed &lt;categorie&gt; namen"> (denk hier maar even over na ;) )
<!ENTITY autoTagPrefix.placeholder   "Voer een label prefix in"> (spatiegebruik)
<!ENTITY fileExceedsLimit.pros1 "Verstuur bestanden en mappen tot 2GB"> (infinitief)
<!ENTITY fileExceedsLimit.pros2 "Sla onbeperkt bestanden online op"> (inf)
<!ENTITY fileExceedsQuota.storageLimitReached   "Ruimtequota bereikt"> (zie de pas toegepaste patch voor quota voor inzage in juiste vertaling van ev en mv van quota)
<!ENTITY fileExceedsQuota.accept "Upgrade"> (inf)
<!ENTITY fileExceedsQuota.description "U heeft uw accounts ruimtequota van 2GB bereikt."> (Altijd u hebt, NOOIT "u heeft", en "uw accounts.." klopt niet)
<!ENTITY editRemoteContentSettings.label "Niet-ingebedde inhoud opties bewerken…"> (spatiegebruik)

confirmDuplicateFolderRename=Er bestaat al een submap '%1$S' in de map '2%$S'. Wilt u deze map verplaatsen door de nieuwe naam '%3$S' te gebruiken? (we gebruiken ALTIJD curly aanhalingstekens, NOOIT recht - zie Mozilla-vertaalwoordenboek)
saveTemplateErrorTitle=Fout bij bewaren van sjabloon -> (Bewaren kennen we niet, altijd Opslaan en zeker niet allebei)

replaceButton.label=Vervang… (inf)
replaceButton.tooltip=Toon het Zoek- en vervang dialoogvenster (spatiegebruik en infinitief)

<!ENTITY captionMailContent.label "E-Mailinhoud"> (E-mail shrijf je zo, en niet anders, m.a.w. met maar één hoofdletter)

hostContact=Contact met server, inloginformatie verzenden… *  (Weliswaar consistent met gebruik van “inloginformatie” elders, maar dit woord moet uiteindelijk overal “aanmeldingsgegevens” worden)

Kun je e.e.a. nog eens nakijken? Wat mij betreft mag de patch ook worden toegepast en daarna worden gecorrigeerd, maar iets zegt me dat ik voor de volgende release weer geen totale controle van TB ga redden. En omdat de kwaliteit ook niet van mijn correctiewerk afhankelijk moet zijn, is aanpakken bij de bron uiteraard het beste…
Target Milestone: mozilla30 → ---
Hallo Ton,
Ik had de link naar het mozilla-vertaalwoordenboek nog niet gevonden. Nu wel dus... Een vraagje nog over de aanhalingstekens: Zijn er nog regels over wanneer we enkele en wanneer we dubbele aanhalingstekens gebruiken?
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #51)

Goeie vraag… Over het algemeen zijn de verschillen met het gebruik ervan in het Engels niet groot of zelfs niet aanwezig, dus in de regel volgen we ze zoals ze in het Engels zijn. (In het Duits bijvoorbeeld gebruikt men de dubbele aanhalingstekens linksonder, zoals vroeger in het Nederlands.) Wel is er zoals je ziet zowel bij enkele als dubbele aanhalingstekens verschil tussen links en rechts. Doorgaans gebruiken we dubbele bij citaten, en enkele bij afwijkende woorden e.d., en het Engels lijkt zich daar ook aan te houden.

Het is vooral zaak hierop te letten bij eerste edits (Tim: lees je mee?), omdat het zoeken naar ‘rechte’ dubbele aanhalingstekens in de broncode immers wordt bemoeilijkt door het feit dat alle strings in dtd-bestanden tussen dubbele aanhalingstekens staan en ‘echte’ aanhalingstekens dus achteraf niet eenvoudig zijn te vinden. Overigens vervangen we ook &quot; door dubbele gekrulde omdat deze anders alsnog recht worden, en in commentaarregels vervangen we niets.

Gedetailleerde uitleg over de strikte taalregels vind je o.a. bij OnzeTaal en Taalunieversum:
https://onzetaal.nl/taaladvies/advies/aanhalingstekens-dubbele-aanhalingstekens
https://onzetaal.nl/taaladvies/advies/enkele-aanhalingstekens
http://taaladvies.net/taal/advies/vraag/11/dubbele_of_enkele_aanhalingstekens_bij_een_citaat/
Hallo Ton,
Nog een paar vragen over je opmerkingen op mijn patch...
> <!ENTITY autotagEnable.label         "Automatisch labels aanmaken van feed
> &lt;categorie&gt; namen"> (denk hier maar even over na ;) )
Ik heb de woordvolgorde aangepast, maar weet niet zeker of je dat bedoelde of dat de combinatie van het Engelse feed en het Nederlandse categorie en spatiegebruik niet goed is:
"Automatisch labels van feed &lt;categorie&gt; namen aanmaken"
> <!ENTITY autoTagPrefix.placeholder   "Voer een label prefix in">
> (spatiegebruik)
Dit moet ook infinitiefvorm worden, denk ik...
"Een labelprefix invoeren"
> <!ENTITY editRemoteContentSettings.label "Niet-ingebedde inhoud opties
> bewerken…"> (spatiegebruik)
Vind je … inhoud-opties duidelijker? Of zelfs … inhoudsopties en … inhoudsvoorkeuren? Ik blijf het een beetje vreemd vinden, een voorvoegsel dat uit meerdere delen bestaat. Zie ook de volgende entry en het Zoek- en vervangdialoogvenster
"Niet-ingebedde inhoudsopties bewerken…"
"Niet-ingebedde inhoudsvoorkeuren bewerken…"
> hostContact=Contact met server, inloginformatie verzenden… *  (Weliswaar
> consistent met gebruik van “inloginformatie” elders, maar dit woord moet
> uiteindelijk overal “aanmeldingsgegevens” worden)
Zal ik de andere strings onder mail ook direct aanpassen? Ik zie onder suite nog een aantal keer inloginformatie en zelfs een keer aameldingsinformatie. Kan ik daar ook iets mee doen?
Onno voor de suite is er een apparte bug https://bugzilla.mozilla.org/show_bug.cgi?id=457393
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #53)
> Hallo Ton,
> Nog een paar vragen over je opmerkingen op mijn patch...
> > <!ENTITY autotagEnable.label         "Automatisch labels aanmaken van feed
> > &lt;categorie&gt; namen"> (denk hier maar even over na ;) )
> Ik heb de woordvolgorde aangepast, maar weet niet zeker of je dat bedoelde
> of dat de combinatie van het Engelse feed en het Nederlandse categorie en
> spatiegebruik niet goed is:
> "Automatisch labels van feed &lt;categorie&gt; namen aanmaken"

Allebei eigenlijk. :) Onthoud dat je eigenlijk NOOIT 2 zelfstandige naamwoorden achter elkaar kunt zetten, enkele uitzonderingen daargelaten. Ons brein (althans, dat van lezers die foutloos Nederlands verwachten te lezen) raakt hierdoor erg in de war, en helaas maar waar overtreft deze ‘Engelse ziekte’ tegenwoordig de d/t-fouten. Onthoud gewoon dat als je ergens 1 lidwoord voor kunt zetten (de .....feednamen), dat het gewoon 1 zelfstandig naamwoord is dat dan toevallig samenstelling heet (net als fietsenstalling), en dus zonder spaties wordt geschreven. Uitzonderingen zijn termen waar bijvoorbeeld een naam met daarin een spatie voorkomt (de Mozilla Firefox-browser). Dat geldt hier dus voor de huppeldepup-feednaam, en wordt het nodig om koppeltekens te gebruiken.

Het Engels zegt hier  "Automatically create tags from feed &lt;category&gt; names"
Nu heb ik het niet getest, maar het lijkt me dat de &lt; en &gt; de tekens < en > zijn, en category niet staat voor een variabele (ik dacht even van wel). Dan zou het dus inderdaad iets worden als

"Automatisch labels van feed-&lt;categorie&gt;-namen aanmaken" of, als zoiets te lang wordt,
"Automatisch labels van namen van feed-&lt;categorie&gt; aanmaken", hoewel hier 2 maal ‘van’ zichtbaar is. Ik ken echter de context niet en vind het vreemd dat categorie tussen < en > zou komen te staan én is de betekenis me wat onduidelijk. Kijk maar even wat de bedoeling is; wellicht dat speaken bij de buren kan helpen (de, fr etc.).

Overigens even terugkomend op mijn eerste regel in comment 50: ik denk dat "Voeg LaTeX-broncode in:"> hier juist is, dus toch gebiedende wijs, omdat het hier immers wel om een opdracht aan de gebruiker lijkt te gaan.

> > <!ENTITY autoTagPrefix.placeholder   "Voer een label prefix in">
> > (spatiegebruik)
> Dit moet ook infinitiefvorm worden, denk ik...
> "Een labelprefix invoeren"

Ook hier lijkt het een opdracht/actie gericht aan de gebruiker te zijn (wat al gauw zo is bij “Enter ...”), dus “Voer labelprefix in” zou dan goed zijn, behalve dan dat we prefix vaak vervangen door voervoegsel.

> > <!ENTITY editRemoteContentSettings.label "Niet-ingebedde inhoud opties
> > bewerken…"> (spatiegebruik)
> Vind je … inhoud-opties duidelijker? Of zelfs … inhoudsopties en …
> inhoudsvoorkeuren? Ik blijf het een beetje vreemd vinden, een voorvoegsel
> dat uit meerdere delen bestaat. Zie ook de volgende entry en het Zoek- en
> vervangdialoogvenster
> "Niet-ingebedde inhoudsopties bewerken…"
> "Niet-ingebedde inhoudsvoorkeuren bewerken…"

"Edit remote content preferences". Hmm… Het is een trend geweest om voor remote ‘niet-ingebed’  te gebruiken, maar we willen dit juist vervangen door extern waar het kan. Maar waar het om ging is de inhoudsopties c.q. -voorkeuren, dus gewoon aan elkaar, met tussen-s en zonder -, en zeker niet met spatie (ook omdat een spatie tussen 2 zelfstandige naamwoorden kan worden opgevat als krantenkopstijl trouwens, wat helemaal is af te raden). Ik denk echter dat het, omdat het immers niet gaat om de inhoudsopties (of -voorkeuren) die extern zijn, maar wel om opties voor externe inhoud, het beter is om “Opties voor externe inhoud bewerken” te gebruiken, en uiteraard hetzelfde bij Voorkeuren voor…

Wat “Toon het Zoek- en vervang dialoogvenster” betreft: hier zou ik “Het dialoogvenster Zoeken en vervangen” van maken - infinitief, gevolgd door de titeltekst. Dit omdat een knop, venster, menu-item doorgaans vooraan staat, gevolgd door de tekst, zoals ‘de knop Opslaan’ (dus niet de ‘Opslaan-knop’ en zeker niet de ‘Opslaan knop’). Afwijkingen daarin zijn dan bv. wanneer men spreekt over een venster dat Zoeken heet, en wat dan elders een zoekvenster wordt genoemd, maar dat blijkt dan als het goed is in dit geval uit de kleine letter s.

> > hostContact=Contact met server, inloginformatie verzenden… *  (Weliswaar
> > consistent met gebruik van “inloginformatie” elders, maar dit woord moet
> > uiteindelijk overal “aanmeldingsgegevens” worden)
> Zal ik de andere strings onder mail ook direct aanpassen? Ik zie onder suite
> nog een aantal keer inloginformatie en zelfs een keer aameldingsinformatie.
> Kan ik daar ook iets mee doen?

Tim wil zoiets denk ik liever in een aparte actie, maar als je zeker weet dat je zeer snel zo’n patch maakt, zou ik het hier vast meenemen om 2 edits kort achter elkaar te vermijden. Ik zou in elk geval wel liefst overal ‘aanmeldingsgegevens’ zien; MS gebruikt dit overigens ook.

Wat ‘informatie’ betreft: onder ‘information’ wordt dus veelal ‘gegevens’ verstaan, zoals ook in ‘personal information’. Ik meen ook dat ‘inloggen’ tot voor kort niet in de Van Dale stond, en dat het wel zo netjes is om hiervoor ‘aanmelden’ te gebruiken, vandaar. ‘Loggen’ in elk geval nog niet als in de betekenis van het vastleggen in een logboek overigens, vandaar registreren of vastleggen i.p.v. loggen, maar dat terzijde.
Attachment #8417918 - Attachment is obsolete: true
Attachment #8422397 - Flags: review?(tonnes.mb)
Attachment #8422397 - Attachment is obsolete: true
Attachment #8422397 - Flags: review?(tonnes.mb)
Attachment #8422399 - Flags: review?(tonnes.mb)
Hallo Ton,
Ik heb inmiddels hg rechten, dus ik kan de patch toepassen als alles goed is ingesteld. Jij had dat ook aangegeven in comment 50. Wil je de patch nog reviewen, of zal ik hem direct toepassen?
Assignee: dutch.nl → o.e.ekker
QA Contact: dutch.nl
Op advies van Tim heb ik de patch toegepast. Het was nog even sleutelen voordat ik de configuratie goed had, maar het is gelukt... http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/70d916e6246f
Ik had nog een merge conflict in chat/irc.properties en zag toen dat daarin channel soms als kanaal is vertaald en andere keren als ruimte. Het lijkt me beter om dit consequent kanaal of ruimte te noemen, waarbij ruimte mijn persoonlijke voorkeur heeft.
Comment on attachment 8422399 [details] [diff] [review]
Ik had nog een paar strings aangepast, maar geen nieuwe diff gemaakt

Review of attachment 8422399 [details] [diff] [review]:
-----------------------------------------------------------------

Het is niet gebruikelijk dat ik patches review en wilde al voorstellen hem gewoon toe te passen, ook omdat er waarschijnlijk altijd iets overblijft om te verbeteren. ;)

De patch ziet er aardig uit, maar hier toch enkele opmerkingen:

-<!ENTITY feedLocation.placeholder    "Voer een geldige feed-url in om toe te voegen">
+<!ENTITY feedLocation.placeholder    "Voer een geldige feed-URL in om toe te voegen">

De wijziging van url naar URL is blijkbaar geen update en gedaan voor consistentie (waar het in en-US niet consistent is), en dat zie ik graag. Verderop in het bestand bij validateText.label zou dat ook nog kunnen.

+<!ENTITY autotagUsePrefix.label      "Labels vooraf laten gaan door:">

Als je een nette vertaalstijl zoals bv. MS die hanteert wilt aanhouden, deel je in dit soort gevallen de werkwoorden niet op en zou je hier beter ‘laten voorafgaan’ kunnen gebruiken. Ander voorbeeld: "optie die u wilt instellen" i.p.v. "optie die u in wilt stellen".

+<!ENTITY fileExceedsLimit.thatsBigFile2   "is een premiumeigenschap.">

Ik heb niet grondig onderzocht of net als ‘Pro Plus’, ‘premium’ hier een abonnements- of versietype is en dus eigenlijk een hoofdletter zou moeten hebben. In dat geval zou het Premium-eigenschap moeten zijn. Als dat niet zo is, heb ik niks gezegd.

+genericFailureExplanation=Controleer dat uw E-mail & nieuwsgroepaccountinstelling juist zijn en probeer het nogmaals.

Controleer _of_, en verder ‘e-mail- & nieuwsgroepinstellingen…’ (mv)

+<!ENTITY fileExceedsLimit.proIncludes "Upgrade nu om dit bestand te versturen plus:">

Iets roept hier om een komma voor ‘plus’…

+assemblingMessageDone=Bericht samenstellen… Klaar

Ik wil eigenlijk overal Klaar vervangen voor Gereed, maar dat zal dan een aparte actie worden.

+sendLargeMessageWarning=Waarschuwing! U staat op het punt om een bericht van %d bytes te verzenden. Weet u zeker dat u dit wilt doen?

Ik heb zelf de neiging om constructies met "You are about to" niet te letterlijk te vertalen en hiervoor gewoon "U gaat" te gebruiken, wat vaak genoeg zegt.

+postingMessage=Bericht posten…

Er zijn in het verleden mensen geweest die niet van het woord "posten" houden en liever "plaatsen" gebruiken.

+failureOnObjectEmbeddingWhileSaving=Er is een probleem bij het toevoegen van bestand %.200s in het bericht. Wilt u doorgaan met opslaan van het bericht zonder dit bestand?
+## LOCALIZATION NOTE (failureOnObjectEmbeddingWhileSending): argument %.200S is file name/URI of object to be embedded
+failureOnObjectEmbeddingWhileSending=Er is een probleem bij het toevoegen van bestand %.200s in het bericht. Wilt u doorgaan met verzenden van het bericht zonder dit bestand?

Ik zou in beide gevallen "doorgaan met het (opslaan/verzenden)" gebruiken, dus inclusief ‘het’. Let trouwens in het algemeen op ‘verzenden’; in de meeste gevallen gebruiken we dat i.p.v. ‘versturen’.

+## LOCALIZATION NOTE (mailnews.reply_header_authorwrotesingle): #1 is author (name of person replying to)
+mailnews.reply_header_authorwrotesingle=#1 schreef:
+## LOCALIZATION NOTE (mailnews.reply_header_ondateauthorwrote): #1 is author, #2 is date, #3 is time
+mailnews.reply_header_ondateauthorwrote=Op #2 #3, #1 schreef:
+## LOCALIZATION NOTE (mailnews.reply_header_authorwroteondate): #1 is author, #2 is date, #3 is time
+mailnews.reply_header_authorwroteondate=#1 schreef op #2 #3:

Nu blijkbaar eindelijk iets is gedaan aan de jarenlang bestaande bug waarmee de woordvolgorde in deze constructie voor bepaalde talen een probleem is en we daar niet zo gek lang geleden een noodoplossing voor hebben bedacht (maar ook sowieso), is het goed om hier kritisch naar te kijken. Het lijkt me dat de 2e en 3e regels er als volgt uit moeten zien:

+## LOCALIZATION NOTE (mailnews.reply_header_ondateauthorwrote): #1 is author, #2 is date, #3 is time
+mailnews.reply_header_ondateauthorwrote=Op #2 om #3 schreef #1:
+## LOCALIZATION NOTE (mailnews.reply_header_authorwroteondate): #1 is author, #2 is date, #3 is time
+mailnews.reply_header_authorwroteondate=#1 schreef op #2 om #3:

+<!ENTITY  chatNotifications.label             "Als er berichten aan u geadresseerd arriveren:">
+<!ENTITY  desktopChatNotifications.label      "Notificatie tonen">

Ik zou in de bovenste regel kiezen voor "aan u geadresseerde berichten", en daaronder het woord ‘melding’ gebruiken voor notification. Dat laatste is echter een actie die eigenlijk globaal moet worden uitgevoerd als er geen bezwaar tegen is, waarbij ook access keys in acht moeten worden genomen.

+imagepermissionstext=U kunt specificeren van welke websites en andere niet-ingebedde inhoud afbeeldingen mogen laden. U kunt niet-ingebedde inhoud ook toestaan op basis van het e-mailadres van de afzender. Type het adres van de website of het e-mailadres dat u wilt beheren en klik dan Blokkeren of Toestaan. 
+imagepermissionstitle=Uitzonderingen - Niet-ingebedde inhoud

In de eerste regel zal het denk ik "afbeeldingen mogen worden geladen" moeten zijn, en voor specificeren kunnen we in het algemeen ook ‘opgeven’ gebruiken. En uiteraard kan ‘niet-ingebedde’ hier ook ‘externe’ worden. Verder klikken we altijd _op_ iets (…op Blokkeren of…) en is de 1e persoon enkelvoud en gebiedende wijs van typen ‘typ’, dus zonder e.
Attachment #8422399 - Flags: review?(tonnes.mb) → review+
N.a.v. comment 61: ik zou e-mail- _en_ nieuwsgroepinstellingen gebruiken, omdat de & in het Nederlands doorgaans wordt vervangen door ‘en’, tenzij in korte omschrijvingen (waaruit hier blijkbaar is gekopieerd?).

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #60)
> Ik had nog een merge conflict in chat/irc.properties en zag toen dat daarin
> channel soms als kanaal is vertaald en andere keren als ruimte. Het lijkt me
> beter om dit consequent kanaal of ruimte te noemen, waarbij ruimte mijn
> persoonlijke voorkeur heeft.

Er is een verschil tussen een channel en een room, dus ik zou voor channel gewoon kanaal aanhouden.

Ik zie trouwens in zowel changeset http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/0f2b3dc5e3dcals als in http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/a9965c0218c5 wijzigingen die ik graag aangepast of teruggedraaid wil zien:

+message.alreadyInChannel=%1$S is al in %2$S.
Ik zou "is al" vermijden en in zo'n geval "bevindt zich al" gebruiken, dus zoals het was.

+error.sendMessageFailed=Er is een fout opgetreden bij het versturen van uw laatste bericht. Probeer het nog een keer als de verbinding hersteld is.

"Nog een keer" is teletubbietaal (opnieuw of nogmaals is beter), versturen zou ik niet gebruiken en ik zou eindigen met "verbinding is hersteld". Maak er een gewoonte van om werkwoordsvormen van zijn, worden en hebben (en dus hier ‘is’) niet achteraan te plaatsen; dit is doorgaans spreektaal of "groene stijl" en wordt in zichzelf respecterende vertalingen vermeden.

In hetzelfde irc.properties staat overigens nog het foutieve ‘teveel’, maar er staan waarschijnlijk wel meer fouten in. Wellicht kun je ook bij de vertaling van Instantbird speaken voor de irc-bestanden; het meeste is daaruit afkomstig.

Tot slot zou ik het waarderen als je (voorlopig) wijzigingen in patchvorm aangeeft in plaats van direct toe te passen om daarmee bovenstaande kwesties te vermijden.
Ik hoop dat ik nog wat handiger met hg wordt... In ieder geval heb ik uiteindelijk de opmerkingen van Ton verwerkt:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4b65e1a883da
+sendLargeMessageWarning=Waarschuwing! U gaat een bericht van %d bytes te verzenden. Weet u zeker dat u dit wilt doen?

Hier staat nog een ‘te’ in a.g.v. wat er eerder stond - let hierop bij correcties als deze, dus lees de zin altijd enkele malen langzaam opnieuw na een bewerking. Dit moet trouwens altijd gebeuren bij vertalingen, dus wie de schoen past…

Een goed en bestaand voorbeeld dat ik toevallig tegenkwam: zoek maar eens naar het woord ‘karater’. Niet alleen erg slordig omdat typefouten gewoonweg zijn te vermijden, maar ook onwetend, daar we jaren geleden al hebben besproken dat karakters o.a. in Japan worden gebruikt en bij gewoon letterschrift een character een teken is… Als je dit wil aanpassen: graag het volgende gebruiken:

Het uploaden van %2$S naar %1$S zorgt voor meer dan 120 tekens in de naam. Hernoem het bestand zodat het 120 of minder tekens in de naam heeft en upload het opnieuw.

(Ja, ook in en-US klopt er iets niet ;) )

Controleer je ook de access keys via Transvision? Ik zie er 1 voor mail die niet zou kloppen, wat al een tijdje het geval is. Ik weet niet waar deze staat omdat ik (vanwege de vervuiling) geen huidige TB gebruik. Over Suite zal ik maar niet beginnen…
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/b8e0d66a84e0

Je had het in comment #62 over 'teveel'. Ik zie wel 'te veel' in het bestand staan, is dat fout? Ik kon de overeenkomstige string niet vinden bij de bestanden van Instantbird...

Ik doe mijn best met de accesskeys, maar vind het lastig omdat de volgorde vaak niet logisch is. Als je eerst de string hebt en meteen daarna de bijbehorende accesskey, zie je veel sneller of de accesskey klopt. Weet je nog een makkelijke manier om dat met Transvision te controleren? En welke accesskey voor welke string zag je die misschien niet niet klopt?
Dank voor de aanpassingen.

Wat ‘teveel’ betreft, dit was al rechtgezet in een eerdere wijziging (http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/95ca9a5dcd85 - ik dacht per abuis te hebben gezien dat dit juist ergens in jouw patch werd toegevoegd i.p.v. aangepast). Ter referentie: _een_ teveel is een zelfstandig naamwoord en tegenhanger van een tekort (bv. aan iets, dus een overschot), terwijl te veel (als tegenhanger van te weinig; kanalen o.i.d.) dus los is - zie ook https://onzetaal.nl/taaladvies/advies/teveel-te-veel.

De access keys zijn snel te controleren via de optie in Transvision - http://transvision.mozfr.org/accesskeys/ . Het gaat dus om de r in AIM, te vinden in het tabblad Chat in het adresboek bij bewerken van een contact. Dit is wellicht een gevolg van te weinig access keys, omdat dit blijkbaar ook zo is in en-US, en deze r werkt ook niet omdat hij al bezet is. Het lijkt er echter op dat de b nog beschikbaar is (voor IRC-bijnaam), dus misschien dat je dat lokaal kunt proberen, zodat de r kan werken, al zit hij natuurlijk niet in AIM. Maar… de a voor Chat werkt ook niet, ondanks dat deze slechts 1 keer in het tabblad voorkomt. Dit terwijl er een jarenlange bug zou zijn verholpen die gebruik van dezelfde key binnen een venster (maar in een ander tabblad) toestaat.

Hoe dan ook, ik ben benieuwd wat er gebeurt als de h voor Chat wordt gebruikt; de R in IRC-bijnaam kan dan zo blijven. Als daarmee de key voor Chat werkt, zou je de A voor AIM kunnen proberen. Misschien dat hij daarin wel werkt, omdat hij dan wel in andere tabbladen wordt gedeeld, maar niet met de tabbladtitels.

Kleinigheidje: probeer access keys hoofdlettergevoelig te houden, dus bv. een A bij AIM. Het lijkt niet nodig maar is technisch een fractie sneller en staat wat netter in vertalingen, en het kan verwarring voorkomen als de letter vaker voorkomt of een string later wordt aangepast (denk bv. aan de l in Livebladwijzers). Probeer ook access keys als q, p, j en g (als kleine letter) te vermijden om cosmetische redenen; dit staat ergens in een guideline van Mozilla.
Verbeterde accesskeys bij eigenschappen contactpersoon: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/3939b43bd463
Attached patch tb32.0a2.patch.1 (obsolete) — Splinter Review
Nieuwe ronde, nieuwe kansen: tb32.0a2...
Attachment #8422399 - Attachment is obsolete: true
Citaat Ton:

> Comment on attachment 8422399 [details] [diff] [review]
> Ik had nog een paar strings aangepast, maar geen nieuwe diff gemaakt
> 
> Review of attachment 8422399 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Het is niet gebruikelijk dat ik patches review en wilde al voorstellen hem
> gewoon toe te passen, ook omdat er waarschijnlijk altijd iets overblijft om
> te verbeteren. ;)

Ik zou willen voorstellen dat je patches meteen toepast (dus niet aan deze bug hangt), als Ton een fout ziet/ suggestie heeft doet hij dat hier.
Hoi Tim Maks,
Dat het reviewen niet gebruikelijk is, sloeg volgens mij op het feit dat ik bij de patch de review? flag had aangezet. In comment #62 vraagt Ton juist om wijzigingen voorlopig eerst als patch aan te leveren…
charsetTitles.properties is verplaatst van dom naar mail en suite, ik heb dat voor nl nu ook gedaan (mail: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/adc2629d59b6)

vergeet niet om een hg pull -u te doen voordat je verder gaat werken aan mail (bijv de patch toepassen)
Ik had dat bestand ook vertaald, maar had daarbij zoveel mogelijk de namen aangehouden zoals ze in Firefox onder Beeld -> Tekenset staan. Ik had dus bijvoorbeeld "Chinees, traditioneel (Big5)" in plaats van "Traditioneel Chinees (Big5)"...
Ik vind het zoals het nu is mooier, maar misschien zou het in Firefox dan ook "Traditioneel Chinees" moeten worden?
Het betreffende bestand zat niet in je pach (had je wel hg add gedaan voordat je de patch maakte?) dus ik ging er vanuit dat je dat niet vertaald had.

Ik heb het bestand zoals hij onder dom bestond een op een over gezet. 

dat het verschilt met de tekenset uit firefox klopt want die is in het engels ook anders : http://transvision.mozfr.org/?recherche=Traditioneel+Chinees&repo=beta&sourcelocale=en-US&locale=nl&search_type=strings
Ik was de hg add misschien vergeten. Ik zag nog een bestand dat in mijn patch ontbreekt (chat/imtooltips.properties). Even kijken hoe ik de boel nu weer lokaal kan herstellen, zodat er een goeie nieuwe patch uit rolt...
Attachment #8438638 - Attachment is obsolete: true
Attached patch Access keys: g eruit e.a. (obsolete) — Splinter Review
Het volgende: gebruik van de kleine g als access key is NIET WENSELIJK en zou bekend moeten zijn. Dit geldt ook voor andere keys die de leesbaarheid verpesten (zoals p, q, y, i en j) en is een algemene Mozilla-regel. Ik wil dit dus ook niet terugzien in TB, noch elders en continue controle hierop is geboden. De hoofdletter G mag uiteraard wel worden gebruikt.

Verder hanteren we altijd hoofdlettergevoelige access keys, oftewel we gebruiken een kleine waar we de kleine willen en een grote waar de grote wordt bedoeld. Dit houdt de boel overzichtelijk en voorkomt per ongeluk verkeerd gekozen/zichtbare keys, is technisch gezien een fractie sneller, was ooit in de gehele bron in orde en ik zou het graag zo houden.

Tot slot: ga uiterst voorzichtig om met het wijzigen van bestaande access keys. Het heeft mij heel wat tijd gekost om conflicten te vermijden en fouten zijn zo gemaakt. Test dus eerst of overleg als het kan.

De patch haalt 3 g’s weg en wijzigt enkele onlangs gewijzigde keys naar wat betere. Graag zou ik zien dat de verantwoordelijke dezelfde correcties op SeaMonkey toepast waar dat van toepassing is.
(In reply to Ton from comment #77)
> Created attachment 8458948 [details] [diff] [review]
> Access keys: g eruit e.a.
> 
> Het volgende: gebruik van de kleine g als access key is NIET WENSELIJK en
> zou bekend moeten zijn. Dit geldt ook voor andere keys die de leesbaarheid
> verpesten (zoals p, q, y, i en j) en is een algemene Mozilla-regel. Ik wil
> dit dus ook niet terugzien in TB, noch elders en continue controle hierop is
> geboden. De hoofdletter G mag uiteraard wel worden gebruikt.

ipv te gaan schreeuwen (hoofdletters gebruiken) plaats hier een link naar de pagina waar die algemene regel(s) staan zodat iedereen die regels kan leren.

> 
> Verder hanteren we altijd hoofdlettergevoelige access keys, oftewel we
> gebruiken een kleine waar we de kleine willen en een grote waar de grote
> wordt bedoeld. Dit houdt de boel overzichtelijk en voorkomt per ongeluk
> verkeerd gekozen/zichtbare keys, is technisch gezien een fractie sneller,
> was ooit in de gehele bron in orde en ik zou het graag zo houden.
> 
> Tot slot: ga uiterst voorzichtig om met het wijzigen van bestaande access
> keys. Het heeft mij heel wat tijd gekost om conflicten te vermijden en
> fouten zijn zo gemaakt. Test dus eerst of overleg als het kan.
> 
> De patch haalt 3 g’s weg en wijzigt enkele onlangs gewijzigde keys naar wat
> betere. Graag zou ik zien dat de verantwoordelijke dezelfde correcties op
> SeaMonkey toepast waar dat van toepassing is.

aub een patch in https://bugzilla.mozilla.org/show_bug.cgi?id=457393 ...
(In reply to Tim Maks van den Broek [:mad_maks] from comment #78)
> 
> ipv te gaan schreeuwen (hoofdletters gebruiken) plaats hier een link naar de
> pagina waar die algemene regel(s) staan zodat iedereen die regels kan leren.

Ik gebruik ze niet om te schreeuwen maar om te benadrukken dat het niet wenselijk is en om het woord verboden te vermijden. En ook omdat dit al zo vaak voorbij is gekomen en de woorden niet zozeer voor Onno maar ook voor jou bedoeld zijn. De vraag waar het staat had ik wel verwacht, maar maakt mijn opmerking nog niet zinloos; mensen kunnen ook zelf e.e.a. opzoeken en vooral onthouden wat in het verleden naar voren is gekomen. Maar goed: https://developer.mozilla.org/en-US/docs/XUL_Accesskey_FAQ_and_Policies

> aub een patch in https://bugzilla.mozilla.org/show_bug.cgi?id=457393 ...

Het is vrij normaal bij Mozilla-code dat de verantwoordelijken hun eigen fouten herstellen, dus ik verwacht dat jij dit (zonder of met dezelfde patch) in orde maakt, wat sneller is dan voor mij, tenzij je mij groen licht geeft om direct naar hg voor SM te schrijven. Zo niet, dan zou ik in jouw plaats mijn uiterste best doen om eigen fouten te herstellen en er vooral van te leren, maar kennelijk vind je nog steeds dat het ook mijn taak is om jouw weer terugkerende fouten te fixen, zelfs als deze twee keer (en dus in SM) worden gemaakt. En dat lijkt me niet de bedoeling.
(In reply to Ton from comment #79)
> (In reply to Tim Maks van den Broek [:mad_maks] from comment #78)

> https://developer.mozilla.org/en-US/docs/XUL_Accesskey_FAQ_and_Policies
dank, het is altijd goed om de link naar de documentatie bij te voegen.
Komen de keys nog goed in de bèta?
(In reply to Ton from comment #81)
> Komen de keys nog goed in de bèta?

Ik kan even niet achterhalen waar de foute access keys vandaan komen en ik weet niet of ik deze in bèta aan mag passen. Ik had van mad_maks begrepen dat er normaal gesproken alleen in Aurora gewerkt wordt…
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #82)
> (In reply to Ton from comment #81)
> > Komen de keys nog goed in de bèta?
> 
> Ik kan even niet achterhalen waar de foute access keys vandaan komen en ik
> weet niet of ik deze in bèta aan mag passen. Ik had van mad_maks begrepen
> dat er normaal gesproken alleen in Aurora gewerkt wordt…

Onno het gaat hier om de patch die Ton gemaakt heeft, als jij het er mee eens bent zal ik hem nog toe passen op beta. Foute acceskeys is een reden om de regel om niet in beta te werken kan breken
Hoi Tim Maks,
De patch ziet er goed uit, de accesskeys voldoen aan alle voorwaarden en Ton heeft er ook nog een dubbele accesskey uitgehaald bij Chat bijwonen. Pas jij de patch op beta toe, dan zorg ik dat aurora goed komt.
Onno
Comment on attachment 8458948 [details] [diff] [review] [diff] [review]
Access keys: g eruit e.a.

Vraag niet hoe, maar ik heb hem ook toegepast op aurora. Er kwam weer eens een merge aan te pas. Misschien moet ik de volgende keer bij importeren niet direct comitten?
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/cfa078144560

Zal ik de patch ook op mozilla-central uitvoeren of doe jij dat, Tim Maks?
Je moet altijd voordat je iets gaan doen een hg pull-u doen, je had lokaal nog een verouderde versie van de rep staan en er werken meer mensen in de nl-rep. Maar toepassen en daarna hg merge en hg commit werkt uiteindelijk ook.

Het werk in aurora pas ik regelmatig ook toe op central dus daar hoef je je niet druk over te maken.
Onno over 10 dagen gaat aurora naar beta, werk jij aurora voor die tijd nog bij?
2 september toch? Hoe lang van te voren is gebruikelijk? Het moet nog gecontroleerd kunnen worden, maar als je het te lang van te voren doet, kunnen er nog wijzigingen komen...
Aurora wordt in principe niet meer gewijzigd (en-US) dus op het moment dat er een overgang is van central naar aurora kan je (bijna) zonder risico aan de vertaling werken. Hoe eerder hoe meer tijd er is voor controle.
Bestanden buiten de map 'mail' maar die wel voor thunderbird gebruikt worden gaan via bug 1064769
Status: NEW → ASSIGNED
Mappen die momenteel alleen voor thunderbird gebruikt worden zoals chat gaan wel via deze bug
Attachment #8445839 - Attachment is obsolete: true
Attachment #8458948 - Attachment is obsolete: true
Oude patches waren al toegepast, nieuwe patch nu ook:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/0f57098afda8
Terugbladerend naar comment #c31 zie ik nog de wens om ‘niet-ingebedde’ door ‘externe’ te vervangen. Is het goed als ik dat op pak? Er zal een aparte patch voor SeaMonkey moeten komen (In bug 457393? Is er geen mozilla-aurora/nl SeaMonkey bug?)
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #95)
> Terugbladerend naar comment #c31 zie ik nog de wens om ‘niet-ingebedde’ door
> ‘externe’ te vervangen. Is het goed als ik dat op pak? Er zal een aparte
> patch voor SeaMonkey moeten komen (In bug 457393? Is er geen
> mozilla-aurora/nl SeaMonkey bug?)

Graag! inderdaad graag een aparte patch voor seamonkey in bug 457393
Attached patch niet-ingebed.patch (obsolete) — Splinter Review
Er zat volgens mij nog een fout in de woordvolgorde bij mail/chrome/messenger/preferences/preferences.properties bij de entity imagepermissionstext, dus dat heb ik ook aangepast. SeaMonkey patch aanleveren kan nog even duren, want dan moet ik eerst SeaMonkey nl downloaden...
+imagepermissionstext=U kunt specificeren van welke websites afbeeldingen en andere externe inhoud mogen laden. U kunt externe inhoud ook toestaan op basis van het e-mailadres van de afzender. Type het adres van de website of het e-mailadres dat u wilt beheren en klik dan Blokkeren of Toestaan.

- In sommige gevallen is ‘opgeven’ een betere term i.p.v. specificeren, ik denk ook hier. Verder klopt deze zin niet; hij zou met ‘mogen worden geladen’ moeten eindigen.
- De tweede zin begint hier eveneens met ‘U kunt’; ik zou het iets anders vormgeven om dat te vermijden (Externe inhoud kunt u ook… / Ook kunt u externe inhoud…)
- ‘Typ’ schrijf je zo.
- We klikken altijd _op_ iets. Soortgelijke strings gebruiken dus ‘en klik vervolgens op’ (of daarna, maar geen dan) en zijn ietwat inconsistent (aangeven/specificeren). Ik zou deze ook meteen meenemen en dan opgeven gebruiken; aangeven is eigenlijk ook niet goed en zal ik proberen mee te nemen bij een Fx-controle.

http://transvision.mozfr.org/?recherche=specify+then+click&repo=release&sourcelocale=en-US&locale=nl&search_type=strings
Verbazingwekkend hoeveel fouten er in een enkele string kunnen zitten...
Bedankt voor je opmerkingen, ik hoop dat ik ze zo allemaal goed verwerkt heb:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/36ef3fd407ea
Bijna… :)
> van welke websites afbeeldingen en andere externe inhoud mogen laden.

=> van welke websites afbeeldingen en andere externe inhoud mogen worden geladen.

(Het is dat hier een constructie met ‘from’ wordt gebruikt en de zin er dus net iets anders uitziet dan de overige)

Verder zou je ‘opgeven’ in cookiepermissionstext kunnen meenemen.

Probeer er een gewoonte van te maken zinnen goed en niet te snel te lezen, als het kan nogmaals na de gemaakte wijzigingen. Zelf controleer ik doorgaans alles wat gewijzigd gaat worden nogmaals in hg vóór het maken van een patch of commit, dat geeft dan een frisse blik (diff met kleuren) en dus nog minder kans op fouten. Ook kun je uit Transvision veel info halen; let vooral op consistentie, dat is heel wat waard. Uiteraard werkt dat ook omgekeerd, dus als je iets nieuws tegenkomt wat niet klopt, verbeterd kan worden of is verbeterd, kan dat ook elders gebeuren.
De frisse blik in hg diff met kleuren werkt bij mij helaas niet goed, omdat de regels uit beeld lopen en er geen scrollbar in mijn mingw32 venster is. Als ik de output naar less pipe worden de regels wel netjes gewrapt, maar dan ben ik de kleuren weer kwijt.

http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4909d2f86088
Voor tb-aurora 35.0a2 hoefde ik alleen maar een paar strings te verwijderen...
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/d09777d6b50b
Een aantal versies geleden hebben we in Firefox 'diensten' vervangen voor 'services', dit is Thunderbird nog niet gedaan http://transvision.mozfr.org/?recherche=services&repo=aurora&sourcelocale=en-US&locale=nl&search_type=strings

wellicht iets voor deze rustige periode.....
Goed idee. Onno, regel jij dit, of…? Tim, doe jij dit voor Suite?

Let wel op 2 zaken:
- ‘Voorzieningen’ blijft gelden bij Mac
- Er zijn wat teksten waarin Diensten wellicht wel juist is, o.a. aboutRights etc.

M.n. het tweede punt gaat denk ik discussie opleveren, maar dat is denk ik wel een goede zaak.

Omdat het inderdaad wat rustiger is en ik door omstandigheden ook wat meer tijd heb, zou het fijn zijn als deze aanpassing niet te lang duurt, zodat ik wellicht eindelijk TB volledig kan nalopen en patches dus niet gaan conflicteren. Maar geen haast…
De query van Tim selecteert op services, maar diensten (en voorzieningen?) moet toch juist door services vervangen worden? Ik kom echter de tekst diensten alleen tegen bij aboutRights en suite en voorzieningen alleen voor de Mac en bij suite…
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #106)
> De query van Tim selecteert op services, maar diensten (en voorzieningen?)
> moet toch juist door services vervangen worden? Ik kom echter de tekst
> diensten alleen tegen bij aboutRights en suite en voorzieningen alleen voor
> de Mac en bij suite…

Ik zag vaak diensten als ik op services zocht maar inderdaad is dat het mac menu en aboutright (dat volgens ton niet aangepast moet worden) dus ik ben te snel geweest met mijn opmerking hier.
Een eerste deel van een totale controle vanaf de laatste keer dat ik dit heb gedaan. Ik ben begonnen op alfabetische volgorde; de patch betreft de mappen mail/chrome/communicator en (alleen) de submappen van mail/chrome/messenger.

Het kan zijn dat hier en daar wat meer dingetjes zijn meegenomen, zoals overbodige klemtonen op ‘een’, versturen -> verzenden, notificaties -> meldingen en wat komma’s. Het lijkt me handig als voor het nalopen op bv. klaar/versturen/notificatis aparte patches komen, liefst voor de hele bron en dus niet per product, tenzij anders gewenst.
Omdat ik momenteel bezig ben met de bestanden in de map messenger, dit nog gebeurt op basis van 35a en er een merge/overgang naar 36a gaande is: kunnen we afspreken dat de bovenstaande en volgende patch vóór het bijwerken voor 36 worden toegepast? Dit uiteraard i.v.m. niet werken ervan door conflicten. Ik kan ook meteen de gewijzigde bestanden voor 36 meenemen, al is gescheiden houden ervan wellicht beter en ook wat makkelijker. Of liever eerst bijwerken (Onno) en een nieuwe patch op basis daarvan maken?
De helft van de bestanden in chrome/messenger, a t/m i.
Attachment #8491420 - Attachment is obsolete: true
Comment on attachment 8529852 [details] [diff] [review]
Controle TB vanaf 26-04-12 deel 1

Review of attachment 8529852 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/chrome/messenger/addressbook/ldapAutoCompErrs.properties
@@ +65,4 @@
>  
>  ## @name INVALID_SYNTAX_HINT
>  ## @loc none
> +10021=Ga na of het zoekfilter juist is en probeer het opnieuw, of neem anders contact op met uw systeembeheerder. Om na te gaan of het zoekfilter juist is kiest u Opties in het menu Extra, Opstellen en vervolgens Adressering. Klik op Directory’s bewerken en selecteer de gebruikte LDAP-server. Klik op Bewerken en vervolgens op Geavanceerd om het zoekfilter weer te geven.

Ik heb vroeger geleerd dat er wel een komma hoort tussen "juist is" en "kiest u"...

@@ +69,4 @@
>  
>  ## @name NO_SUCH_OBJECT_HINT
>  ## @loc none
> +10032=Ga na of de basis-DN juist is en probeer het vervolgens opnieuw, of neem anders contact op met uw systeembeheerder. Om na te gaan of de basis-DN juist is kiest u Opties in het menu Extra, Opstellen en vervolgens Adressering. Klik op Directory’s bewerken en selecteer de gebruikte LDAP-server. Klik op Bewerken om de basis-DN weer te geven.

Zie vorige commentaar

@@ +77,4 @@
>  
>  ## @name SERVER_DOWN_HINT
>  ## @loc none
> +10081=Ga na of de hostnaam en het poortnummer juist zijn en probeer het opnieuw, of neem anders contact op met uw systeembeheerder. Om na te gaan of de hostnaam en het poortnummer juist zijn kiest u Opties in het menu Extra, Opstellen en vervolgens Adressering. Klik op Directory’s bewerken en selecteer de gebruikte LDAP-server. Klik op Bewerken om de hostnaam en het poortnummer weer te geven.

Zie vorige commentaar, maar dan tussen "juist zijn" en "kiest u".

@@ +85,4 @@
>  
>  ## @name FILTER_ERROR_HINT
>  ## @loc none
> +10087=Ga na of het zoekfilter juist is en probeer het opnieuw, of neem anders contact op met uw systeembeheerder. Om na te gaan of het zoekfilter juist is kiest u Opties in het menu Extra, Opstellen en vervolgens Adressering. Klik op Directory’s bewerken en selecteer de gebruikte LDAP-server. Klik op Bewerken en vervolgens op Geavanceerd om het zoekfilter weer te geven.

Zie vorige commentaar

@@ +93,4 @@
>  
>  ## @name CONNECT_ERROR_HINT
>  ## @loc none
> +10091=Ga na of de hostnaam en het poortnummer juist zijn en probeer het opnieuw, of neem anders contact op met uw systeembeheerder. Om na te gaan of de hostnaam en het poortnummer juist zijn kiest u Opties in het menu Extra, Opstellen en vervolgens Adressering. Klik op Directory’s bewerken en selecteer de gebruikte LDAP-server. Klik op Bewerken om de hostnaam en het poortnummer weer te geven.

Zie vorige commentaar

@@ +97,4 @@
>  
>  ## @name HOST_NOT_FOUND_HINT
>  ## @loc none
> +15000=Ga na of de hostnaam juist is en probeer het opnieuw, of neem anders contact op met uw systeembeheerder. Om na te gaan of de hostnaam juist is kiest u Opties in het menu Extra, Opstellen en vervolgens Adressering. Klik op Directory’s bewerken en selecteer de gebruikte LDAP-server. Klik op Bewerken om de hostnaam weer te geven.

Zie vorige commentaar
Comment on attachment 8530804 [details] [diff] [review]
Controle TB vanaf 26-04-12 deel 2

Review of attachment 8530804 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/chrome/messenger/FilterEditor.dtd
@@ +35,5 @@
>  <!ENTITY copyMessage.label "Bericht kopiëren naar">
>  <!ENTITY forwardTo.label "Bericht doorsturen naar">
> +<!ENTITY replyWithTemplate.label "Antwoorden met sjabloon">
> +<!ENTITY markMessageRead.label "Markeren als gelezen">
> +<!ENTITY markMessageUnread.label "Narkeren als ongelezen">

Tpyo bij Narkeren

::: mail/chrome/messenger/filter.properties
@@ +9,4 @@
>  cannotHaveDuplicateFilterTitle=Filternaam bestaat al
>  cannotHaveDuplicateFilterMessage=Deze filternaam bestaat al. Voer een andere filternaam in.
>  mustHaveFilterTypeTitle=Geen filtergebeurtenis geselecteerd
> +mustHaveFilterTypeMessage=U moet ten minste één gebeurtenis selecteren waarbij dit filter wordt toegepast. Als u het filter tijdelijk helemaal niet wilt laten uitvoeren, haal dan het vinkje weg bij de inschakelstatus in het dialoogvenster Berichtenfilters.

Moet dit niet ook "een" worden in plaats van "één"?
Ik heb de twee patches van Ton toegepast, waarbij ik in eerste instantie alleen Narkeren heb veranderd in Markeren. http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/1237d006c7cb
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #111)

In alle 6 gevallen kan er inderdaad een komma tussen ter verduidelijking. Strikt genomen hoeft het meen ik niet vanwege de “om”-constructie, hoewel dat denk ik bij kortere zinnen geldt en hier alleen al de lengtes van de bepalingen in het eerste deel van de zin toelaten om het wel te doen. In bv. “Om langs te komen hoeft u niet …” zou het niet hoeven. Maak jij dit in orde?

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

> > +mustHaveFilterTypeMessage=U moet ten minste één gebeurtenis selecteren waarbij dit filter wordt toegepast. Als u het filter tijdelijk helemaal niet wilt laten uitvoeren, haal dan het vinkje weg bij de inschakelstatus in het dialoogvenster Berichtenfilters.
> 
> Moet dit niet ook "een" worden in plaats van "één"?

Het lijkt hier om een nadrukkelijk telwoord te gaan (“at least one event”), dus niet om een uitdrukking zoals “een of meer” waarbij de klemtoon niet nodig is. (Zie ook http://taaladvies.net/taal/advies/vraag/238).

Wilde je overigens eerst de boel bijwerken voordat ik hiermee verder ga? Door omstandigheden kan ik waarschijnlijk na vandaag toch weer een aantal weken niets doen…

@ Tim: ben jij van plan deze patches ook op SM toe te passen als/waar dat kan?
Ik had tb-aurora al bijgewerkt, maar de overgang van central naar aurora was al gebeurd. Ik weet niet zeker of ik de patches ook op central kan/mag toepassen, of dat Tim dat moet doen...
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #117)
> tb-aurora 36.0a2:
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/bdef7bfc8993

+<!ENTITY fileExceedsLimit.thatsBigFile3 "Het verzenden van bestanden groter dan 50 MB wordt niet ondersteund voor niet-Premiumaccounts">

De grote P waar Engels een kleine gebruikt vind ik niet zo belangrijk (beter juist), maar ik zou er wel niet-Premium-accounts van maken, en uiteraard afsluiten met een punt.

+messagesTotalSizeMoreThan=Deze berichten gebruiken meer dan: #1.

Ik dacht even dat de : nog uit het Engels resteerde (omdat men die iets vaker gebruikt in zo’n situatie), maar vermoedelijk heb je hem hier geplaatst omdat ie ook in messagesTotalSize voorkwam. Beide lijken me zeker niet de bedoeling in een zin. Verder zou ik voor take up ‘nemen in beslag’ gebruiken als ik het tegenkom.
(In reply to Ton from comment #118)
> +<!ENTITY fileExceedsLimit.thatsBigFile3 "Het verzenden van bestanden groter
> dan 50 MB wordt niet ondersteund voor niet-Premiumaccounts">
> 
> De grote P waar Engels een kleine gebruikt vind ik niet zo belangrijk (beter
> juist), maar ik zou er wel niet-Premium-accounts van maken, en uiteraard
> afsluiten met een punt.

Het staat er in het Engels ook zo, maar het is misschien mooier om die dubbele ontkenning er uit te halen?
<!ENTITY fileExceedsLimit.thatsBigFile3 "Het verzenden van bestanden groter dan 50 MB wordt alleen ondersteund voor Premium-accounts.">
Attachment #8529852 - Attachment is obsolete: true
Attachment #8530804 - Attachment is obsolete: true
Patches zijn al toegepast, dus attachments zijn nu obsolete
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #116)
> Ik had tb-aurora al bijgewerkt, maar de overgang van central naar aurora was
> al gebeurd. Ik weet niet zeker of ik de patches ook op central kan/mag
> toepassen, of dat Tim dat moet doen...

? je kan gewoon in aurora blijven werken als je en-US overgang gemaakt is.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #120)
> 
> Het staat er in het Engels ook zo, maar het is misschien mooier om die
> dubbele ontkenning er uit te halen?
> <!ENTITY fileExceedsLimit.thatsBigFile3 "Het verzenden van bestanden groter
> dan 50 MB wordt alleen ondersteund voor Premium-accounts.">

Heel goed, volledig mee eens. Ik heb deze info ook in bug 1080587 geplaatst in de hoop dat men in en-US ook zoiets zal doen.
Overigens is het ook mogelijk om ‘ondersteund’ hier achteraan te zetten, maar ik denk dat het hier niet veel zal uitmaken of zelfs niet beter is. Op diverse plekken in de bron zou dat namelijk wel kunnen, vandaar dat ik er even aan dacht.
Onno, wil je als je als committekst meld 'merge aurora into central' dit ook werkelijk doen! je hebt de laatste aanpassingen ook toegepast op central en dat is geen merge!
(In reply to Ton from comment #123)
> 
> (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #120)
> Op diverse plekken in de bron zou dat namelijk wel kunnen, vandaar dat ik…

Ik doelde hier op verbetering van woordvolgorde in het algemeen, niet zozeer op het woord ‘ondersteund’.

(In reply to Tim Maks van den Broek [:mad_maks] from comment #122)
> 
> ? je kan gewoon in aurora blijven werken als je en-US overgang gemaakt is.

Speaking of, begrijp ik dat er door rommeligheid aan en-US-kant een sign-off is gemist en zo ja, wat heeft dit voor gevolgen voor nl?
(In reply to Ton from comment #114)

> @ Tim: ben jij van plan deze patches ook op SM toe te passen als/waar dat
> kan?

ga ik doen...
(In reply to Ton from comment #125)
> (In reply to Ton from comment #123)
> > 
> > (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #120)
> > Op diverse plekken in de bron zou dat namelijk wel kunnen, vandaar dat ik…
> 
> Ik doelde hier op verbetering van woordvolgorde in het algemeen, niet zozeer
> op het woord ‘ondersteund’.
> 
> (In reply to Tim Maks van den Broek [:mad_maks] from comment #122)
> > 
> > ? je kan gewoon in aurora blijven werken als je en-US overgang gemaakt is.
> 
> Speaking of, begrijp ik dat er door rommeligheid aan en-US-kant een sign-off
> is gemist en zo ja, wat heeft dit voor gevolgen voor nl?

hoe bedoel je?

de overgang van aurora naar beta is een week uitgesteld vanwege thanks giving dus 1 dec is het nu gebeurd.
Rest van de bestanden in de map chrome/messenger, met soms wat aanpassingen in bestanden in de vorige 2 patches. Er blijven nog wat keys over die niet werken; deze en andere bepaalde generieke zaken volgen apart.

Klopt het trouwens dat feeds niet werken?
Comment on attachment 8533128 [details] [diff] [review]
Controle TB vanaf 26-04-12 deel 3

Bedankt voor de controle, toegepast: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/3c92c6a3f495
Attachment #8533128 - Attachment is obsolete: true
Tussen de controle door een aparte jacht op "Het is niet gelukt om", opdracht, ingelogd, indien, dubbele key en vast wat gevallen van specificeren -> opgeven. Dit alleen in de tot nu toe nagelopen bestanden.
Iets anders: ik zie in TB de laatste tijd 2 dingen:

- Het is alsof in het optiesvenster alles wordt opgerekt in de breedte, wat met name te zien is aan de breedte van de knoppen in de tabs Algemeen, Categorieën en Tijdzone als Lightning is geïnstalleerd, maar ook zonder Lightning. Dit ook zo bij gebruik van een nieuw profiel en/of Lightning 2.6. Wellicht dat het venster in het algemeen wat te breed is, maar ik gelofo niet dat het oprekken daarbij hoort.
- Venstergroottes van opties- en accountinstellingenvensters in TB worden niet onthouden.

Dit alles onder Windows. Hebben meer mensen hier last van?
Het opgerekte optiesvenster heb ik nog nooit gezien.

In je laatste patch schrijf je "IDLE-opdracht", in de vorige patch heb je het steeds over "De opdracht IDLE". Het is dan denk ik consistenter om die schrijfwijze ook hier aan te houden.

Bji imapServerDroppedConnection heb je het over "uitgebreide IMAP-serverinstellingen". In het serverinstellingenscherm staat de knop Geavanceerd…, het lijkt me dan ook beter om hier "geavanceerde IMAP-serverinstellingen" te gebruiken.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #132)
> Het opgerekte optiesvenster heb ik nog nooit gezien.

Is dit onder Windows en zo ja, welke versie(s)? Wat ik bedoel is de inhoud van het venster; knoppen staan vaak helemaal tgen de rechterkant van het venster en vervolgkeuzemenu's en soms knoppen zijn onnodig lang, zoals in de panelen Weergave (tab Opmaak), Opstellen (tab Adressering) en Privacy. Voorbeeld voor Lightning: http://imagebin.ca/v/1kUdiaqJBMqG .

> In je laatste patch schrijf je "IDLE-opdracht", in de vorige patch heb je
> het steeds over "De opdracht IDLE". Het is dan denk ik consistenter om die
> schrijfwijze ook hier aan te houden.

Ik heb dit inderdaad overwogen maar het toch maar zo gelaten, omdat ik dit geval niet zo ernstig vond. Als menu-optie dient het immers niet te lang te zijn, het lidwoord ontbreekt, vandaar eigenlijk. Maar als je wilt mag het wat mij betreft ook "Opdracht IDLE" worden, eventueel met "De" ervoor.

> Bji imapServerDroppedConnection heb je het over "uitgebreide
> IMAP-serverinstellingen". In het serverinstellingenscherm staat de knop
> Geavanceerd…, het lijkt me dan ook beter om hier "geavanceerde
> IMAP-serverinstellingen" te gebruiken.

Dit stond er al zo in maar goed gezien, make it so. Ik vind Uitgebreid voor Advanced toch al een beetje misplaatst (dit komt vaker voor), uitzonderingen daargelaten.

Overigens zul je wel gezien hebben dat de Engelse terminolgie hier niet helemaal juist is; het betreffende dialoogvenster heeft een andere titel en "Advanced IMAP Server Settings" komt niet letterlijk voor. Maar zo klopt er wel meer niet; imapAuthChangeEncryptToPlainSSL heeft het bv. over "Normaal wachtwoord" waar deze term al even uit TB is verdwenen, maar dat terzijde.
(In reply to Ton from comment #133)
> (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #132)
> > Het opgerekte optiesvenster heb ik nog nooit gezien.
> 
> Is dit onder Windows en zo ja, welke versie(s)? Wat ik bedoel is de inhoud
> van het venster; knoppen staan vaak helemaal tgen de rechterkant van het
> venster en vervolgkeuzemenu's en soms knoppen zijn onnodig lang, zoals in de
> panelen Weergave (tab Opmaak), Opstellen (tab Adressering) en Privacy.
> Voorbeeld voor Lightning: http://imagebin.ca/v/1kUdiaqJBMqG .

Ik zie wat je bedoelt. Ik heb Windows 7 TB 36.0a2 Aurora nl en zie daar bij Opstellen tab Addressering inderdaad wat lange velden voor de drop-downlists bij Directoryserver en E-mailadressen toevoegen, maar heb dat ook bij Windows XP TB 31 Release en-US.
Comment on attachment 8536171 [details] [diff] [review]
Diverse zaken in /messenger en submappen

Patch toegepast met kleine wijziging geavanceerd i.p.v. uitgebreid.
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4083d6189bc6
Attachment #8536171 - Attachment is obsolete: true
(In reply to Tim Maks van den Broek [:mad_maks] from comment #127)
> (In reply to Ton from comment #125)
> > (In reply to Ton from comment #123)
> > > 
> > > (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #120)
> > > Op diverse plekken in de bron zou dat namelijk wel kunnen, vandaar dat ik…
> > 
> > Ik doelde hier op verbetering van woordvolgorde in het algemeen, niet zozeer
> > op het woord ‘ondersteund’.
> > 
> > (In reply to Tim Maks van den Broek [:mad_maks] from comment #122)
> > > 
> > > ? je kan gewoon in aurora blijven werken als je en-US overgang gemaakt is.
> > 
> > Speaking of, begrijp ik dat er door rommeligheid aan en-US-kant een sign-off
> > is gemist en zo ja, wat heeft dit voor gevolgen voor nl?
> 
> hoe bedoel je?
> 
> de overgang van aurora naar beta is een week uitgesteld vanwege thanks
> giving dus 1 dec is het nu gebeurd.

Hoe zit het nu met die sign-offs? Ik snap het nog niet helemaal, maar op https://l10n.mozilla.org/teams/nl staan de sign-offs voor tb_aurora 36 en tb_beta 35 nog in review...

Wie moet hier dan nog iets voor doen of kan dat pas bij de volgende update?
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #136)

> Hoe zit het nu met die sign-offs? Ik snap het nog niet helemaal, maar op
> https://l10n.mozilla.org/teams/nl staan de sign-offs voor tb_aurora 36 en
> tb_beta 35 nog in review...
> 
> Wie moet hier dan nog iets voor doen of kan dat pas bij de volgende update?

De sign off doe ik momenteel nog als ik zie dat de controle patch van die versie toegepast is en als jij nog andere veranderingen hebt gemaakt (dus soms een aantal keer in een cycli van aurora). Als jij wilt (en kan inloggen?) is het handig als jij het gaat doen als jij vind dat de versie gereed is waar aan gewerkt wordt.

de review wordt gedaan door de l10n driver van Thunderbird, daar hebben wij geen invloed op.
N.a.v. http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/be09e82c74dc :

+conversation.error.remoteServerNotFound=Kan de server van de ontvanger niet bereiken
 Ik geen er zelf de voorkeur aan om verleden tijd (hier "could") ook in de verleden tijd te vertalen.
 
+<!ENTITY contextOutgoing.label "Na versturen">
Waarom "versturen" i.p.v. verzenden?
 
+<!ENTITY reorderTopButton.accessKey "p">
We zcuden geen p, q, j etc. als access key gebruiken. De e en de a kunnen ook.
 
+errorFilteringMsg=Uw bericht is verzonden en bewaard, maar er is een fout opgetreden bij het toepassen van de berichtenfilters op het bericht.
Waarom bewaard i.p.v. opgeslagen? Wees voorzichtig met "bewaren"; doorgaans gebruikt men dat bij "store".
 
Ik zat hier ook een beetje met "run (filter)", hier ook in de brontekst. Onlangs heb ik dit nog in het filterregelvenster gewijzigd naar "(Nu) uitvoeren" omdat er volgens mij verschil is tussen applying en running, en op dit moment is het in TB nog niet helemaal consistent. Navraag op irc leverde op dat dit wat en-US betreft waarschijnlijk hetzelfde is, en er werd voorgesteld om een bug aan te maken voor en-US om deze verwarring te vermijden.

In dat geval zou ik overal pleiten voor run/uitvoeren, omdat toepassen nu eenmaal impliceert dat dit een actie van de gebruiker is, bv. het activeren van een filter door het aanmaken ervan of het inschakelen via een vinkje. In het menu Extra bijvoorbeeld vind ik dat "Filters toepassen op map" geen uitsluitsel geeft of het nu om direct uitvoeren ervan gaat, of het al dan niet tijdelijk inschakelen voor een map. De voornaamste reden om het onlangs in het filterregelvenster te wijzigen was dat ondanks de tekst "Run filter now" (en dus de toevoeging "filter") "toepassen" daarin kon doen vermoeden dat dit een gebruikersactie was na bv. een verplaatsing of bewerking van een filterregel, terwijl het ook om directe uitvoering ervan gaat. Wellicht is in het Engels op deze plaats ook voor Run gekozen om dit te verduidelijken, en elders wat vaker voor apply.

Anderzijds kunnen we ook zeggen dat we zowel run/uitvoeren als apply/toepassen blijven gebruiken (de kreet "Filter(s) toepassen" / "Apply filter(s)" komt in het algemeen ook wat vaker voor) en het dus zo laten, maar dan zou ik bij "run" wel voor "uitvoeren" kiezen. Mocht het ergens verwarring geven, zou ik zelfs 'apply" als "uitvoeren" vertalen.Meningen?

+<!ENTITY allowHWAccel.accesskey        "H">
Ter info: misschien is het opgevallen dat keys in FF en TB doorgaans hetzelfde zijn gekozen, tenzij onmogelijk. Het zou hier een beetje "niet in lijn" zijn om dat te doen gezien de overige opties, dus geen bezwaar tegen de H. Wel is er een tijd geweest dat in de optiesvensters sprake was van een knop Help (die inmiddels weer is verwijderd), waardoor overige H-keys natuurlijk moesten worden aangepast. Hou daarom in het algemeen wel rekening met gebruik van de H, is het niet omdat deze ooit misschien weer wel voor zo'n knop wordt gebruikt, dan wel omdat deze makkelijk conflicteert met de H voor Help in de hoofdmenubalk.

+<!ENTITY  overridePageColors.label        "De kleuren opgegeven door de inhoud overschrijven met mijn selecties hierboven:">
Ik zou hier "De door de inhoud opgegeven kleuren overschrijven met mijn selecties hierboven:" gebruiken om verwarring bij "kleuren opgegeven" te vermijden (en deze zelfde string trouwens ook in FF gebruiken, (Tim).

+<!ENTITY  overridePageColors.accesskey    "k">
-<!ENTITY  underlineLinks.accesskey        "K">
+<!ENTITY  underlineLinks.accesskey        "o">
Je "kaapt" nu een bestaande K bij "Koppelingen onderstrepen" en vervangt die door een o. Doorgaans probeer ik bestaande keys te behouden, tenzij er een logica achter zit om dat niet te doen. In dit geval waren alle eerste letters de keys, dus enigszins een cosmetische reden. Ik zou de K daarin  behouden en in overridePageColors.label de o (van overschrijven?) gebruiken. 

+<!ENTITY  overridePageColors.auto.label   "Alleen bij thema's met hoog contrast">
Denk aan het (uitsluitend) gebruiken van 'curly' apostrofs en aanhalingstekens, dus hier "thema’s".

N.a.v. http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4bd2984b6607:

+<!ENTITY radioAskState.label "Mij de onlinetoestand vragen">
+<!ENTITY radioAskState.accesskey "M">
Niet getest, maar ik zou de v overwegen; de h in radioRememberPrevState.accesskey is ook vanwege het werkwoord gekozen.
Ton, bedankt voor je review. Ik heb een en ander gecorrigeerd en waar je commentaar vraagt voeg ik dat hieronder toe. De rest van jouw comment trim ik, anders wordt het zo lang…
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/ec6f45e8a61a

(In reply to Ton from comment #139)
> +<!ENTITY contextOutgoing.label "Na versturen">
> Waarom "versturen" i.p.v. verzenden?
Nergens om, foutje, verbeterd…

>  
> +<!ENTITY reorderTopButton.accessKey "p">
> We zcuden geen p, q, j etc. als access key gebruiken. De e en de a kunnen
> ook.
Foutje, verbeterd. Ik probeer er om te denken.

>  
> +errorFilteringMsg=Uw bericht is verzonden en bewaard, maar er is een fout
> opgetreden bij het toepassen van de berichtenfilters op het bericht.
> Waarom bewaard i.p.v. opgeslagen? Wees voorzichtig met "bewaren"; doorgaans
> gebruikt men dat bij "store".
Ik heb hier opgeslagen en uitvoeren van gemaakt. Had je een bug aangemaakt voor en-US? Dan graag het bugnummer vermelden. Ik zie zelf niet zo erg verschil tussen toepassen en uitvoeren of dat toepassen meer een actie van de gebruiker zou zijn, maar het is natuurlijk altijd goed om consistent in je vertaling te blijven…

> +<!ENTITY allowHWAccel.accesskey        "H">
Toch maar veranderd in "v" om gelijkt te blijven met Firefox en geen problemen met eventuele Help in hoofdmenubalk te veroorzaken. SeaMonkey gebruikt weer een andere toets (r)…

> +<!ENTITY  overridePageColors.accesskey    "k">
> -<!ENTITY  underlineLinks.accesskey        "K">
> +<!ENTITY  underlineLinks.accesskey        "o">
> Je "kaapt" nu een bestaande K bij "Koppelingen onderstrepen" en vervangt die
> door een o. Doorgaans probeer ik bestaande keys te behouden, tenzij er een
> logica achter zit om dat niet te doen. In dit geval waren alle eerste
> letters de keys, dus enigszins een cosmetische reden. Ik zou de K daarin 
> behouden en in overridePageColors.label de o (van overschrijven?) gebruiken. 
Ik heb hier scheel gekeken, want ik dacht dat op deze manier allebei accesskeys aan het begin van een woord zouden komen, maar dat klopte ook al niet, omdat er in Koppelingen ook al een o staat. underlineLinks is nu dus terug naar K en voor overridePage Colors heb ik de D ingesteld...
> 
> +<!ENTITY  overridePageColors.auto.label   "Alleen bij thema's met hoog
> contrast">
> Denk aan het (uitsluitend) gebruiken van 'curly' apostrofs en
> aanhalingstekens, dus hier "thema’s".
Oeps, ik prent het me nog een keer in…

> +<!ENTITY radioAskState.label "Mij de onlinetoestand vragen">
> +<!ENTITY radioAskState.accesskey "M">
> Niet getest, maar ik zou de v overwegen; de h in
> radioRememberPrevState.accesskey is ook vanwege het werkwoord gekozen.
De v wordt onderin het scherm al gebruikt bij "Mij vragen" (Wilt u niet-verzonden berichten verzenden als u online gaat?). Anders zou ik die bestaande toets ook moeten wijzigen, maar daar heb ik geen letters meer over (behalve de i en de g die dus niet mogen).
Bedankt, ziet er goed uit.

M.b.t. run/apply:
Aryx (in het kort) heeft bug 1123649 aangemaakt voor 1 string, en wat overige gevallen van apply bekeken. Zijn en de argumentatie erna voor run/apply zijn ook verhelderend.
Het lijke erop dat apply en toepassen in beide taslen wat algemener zijn en dus allebei wel mogen. Het kan wat mij betreft wel zo blijven, maar op dit moment is Run op enkele plaatsen nog, of juist met opzet, vertaald als Toepassen…
tb-38.0a2 is klaar voor controle: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/0b51c7786986

Een paar vragen/opmerkingen:

- Ik wilde “graag” de accesskey van Accountinstellingen in het menu veranderen in "n", omdat de huidige "c" en alle andere letters al gebruikt worden of niet voldoen aan de regels. Mag dat?

- In aboutDownloads.dtd heb ik de string "Tonen in Finder" opgenomen, omdat deze string op veel andere plaatsen ook voor komt. Het zou volgens mij alleen beter zijn om dit te veranderen in "In Finder tonen". Er staan in dit bestand meerdere strings met een verkeerde woordvolgorde, bijvoorbeeld "Verwijderen uit geschiedenis" in plaats van "Uit geschiedenis verwijderen".

- In messenger.properties is bij het Engels de send_default_charset gewijzigd van ISO-8859-1 in UTF-8. Ik heb zelf ook al tijden UTF-8 ingesteld staan bij Opties -> Weergave -> Opmaak -> Lettertype -> Geavanceerd -> Tekensets) en dit werkt volgens mij goed. Kan ik dit aanpassen of zie jij daar nog problemen mee?

- Ik zie dat het woord Telemetry nergens vertaald is, klopt dat?
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #142)

> - Ik wilde “graag” de accesskey van Accountinstellingen in het menu
> veranderen in "n", omdat de huidige "c" en alle andere letters al gebruikt
> worden of niet voldoen aan de regels. Mag dat?

Tja, de c wordt al gebruikt sinds Chatstatus erin is gekomen (http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/aa86c29b75af - nu bijna 3 jaar geleden) en het lijkt erop dat het niet anders kan en zelfs toen al had gekund/gemoeten. Ik zou het maar doen dan. Herinnert me trouwens aan een dubbele key voor Lightning; wellicht moet Lightning (net als andere extensies) daarom worden aangepast, niet andersom.

> - In aboutDownloads.dtd heb ik de string "Tonen in Finder" opgenomen, omdat
> deze string op veel andere plaatsen ook voor komt. Het zou volgens mij
> alleen beter zijn om dit te veranderen in "In Finder tonen". Er staan in dit
> bestand meerdere strings met een verkeerde woordvolgorde, bijvoorbeeld
> "Verwijderen uit geschiedenis" in plaats van "Uit geschiedenis verwijderen".

Dit is opzet (althans van mij) en ooit eens in een bug voorbij gekomen, en soms wijzig ik het juist naar die vorm als het nog ergens met een voorzetsel begint. Ik weet dat MS het niet doet, maar ondanks dat mensen zouden kunnen zeggen dat dit zeg maar "handhaven van de Engelse woordvolgorde" is, beschouw ik het beginnen van opdrachten met een voorzetsel als gevallen van "aan een tak hangen", "in de bres springen" of "uit je nek l*n" en probeer dat vanwege die associatie met opzet te vermijden, tenzij voorafgegaan door een erbij horend zelfstandig naamwoord. Vergelijk bv. "Item uit geschiedenis verwijderen" en "Uit geschiedenis verwijderen" - in het tweede geval vraag ik me bij het beginnen met lezen af om welke actie het gaat en laat me dan afleiden door het voorzetsel, wat niet zo is bij "Verwijderen uit geschiedenis". Een kwestie van voorkeur misschien, maar wel met een reden.

> - In messenger.properties is bij het Engels de send_default_charset
> gewijzigd van ISO-8859-1 in UTF-8. Ik heb zelf ook al tijden UTF-8 ingesteld
> staan bij Opties -> Weergave -> Opmaak -> Lettertype -> Geavanceerd ->
> Tekensets) en dit werkt volgens mij goed. Kan ik dit aanpassen of zie jij
> daar nog problemen mee?

Zo te zien dateert dit uit bug 941545 en heeft die wijziging (voor en-US althans) een jaar geleden plaatsgevonden. Ik hou me eigenlijk niet zo bezig  met dat soort zaken en weet niet of het over het hoofd is gezien of dat er een bepaalde reden voor was, maar het lijkt ook een keuze per locale te zijn. Aangezien alles tegenwoordig wel UTF8 hanteert en dit zo te zien een standaardinstelling betreft, denk ik dat het wel kan, maar helemaal zeker weten doe ik het niet.

> - Ik zie dat het woord Telemetry nergens vertaald is, klopt dat?

Klopt… Ik heb het bewust zo gelaten (en Tim Maks denk ik ook), eigenlijk een beetje omdat het een technisch onderdeel is waarvoor de verwijzende documenten ook vaak in het Engels zijn. Andere talen schijnen het wel te vertalen (zie http://transvision.mozfr.org/string/?entity=browser/chrome/browser/preferences/advanced.dtd:telemetrySection.label), dus we zouden het wel kunnen doen.
Overigens laat ik een term bij twijfel, of als deze elders ook nog niet is vertaald, ook onvertaald met de bedoeling om het natuurlijk consistent te houden en later in één keer of uiteraard zo gelijktijdig mogelijk te doen.
(In reply to Ton from comment #143)
> (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #142)
> 
> > - Ik wilde “graag” de accesskey van Accountinstellingen in het menu
> > veranderen in "n", omdat de huidige "c" en alle andere letters al gebruikt
> > worden of niet voldoen aan de regels. Mag dat?
> 
> Tja, de c wordt al gebruikt sinds Chatstatus erin is gekomen
> (http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/aa86c29b75af - nu
> bijna 3 jaar geleden) en het lijkt erop dat het niet anders kan en zelfs
> toen al had gekund/gemoeten. Ik zou het maar doen dan. Herinnert me trouwens
> aan een dubbele key voor Lightning; wellicht moet Lightning (net als andere
> extensies) daarom worden aangepast, niet andersom.

We kunnen er ook een kleine stoelendans van maken, want de c voor Accountinstellingen is best fijn en wordt door mij in ieder geval veel gebruikt. Chatstatus zou dan bijvoorbeld als accesskey h krijgen , Recente geschiedenis wissen wordt dan r (zal niet zo'n probleem zijn, omdat mensen sneller Ctrl+Shift+Del zullen gebruiken dan de accesskey) en Externe debugverbinding toestaan kan dan r worden.

Er zitten overigens nog twee fout accesskeys in dit menu: Opgeslagen bestanden heeft de l en Importeren heeft de i. Dit kan respectievelijk n en m worden.
(In reply to Ton from comment #143)
> (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #142)
> > - In messenger.properties is bij het Engels de send_default_charset
> > gewijzigd van ISO-8859-1 in UTF-8. Ik heb zelf ook al tijden UTF-8 ingesteld
> > staan bij Opties -> Weergave -> Opmaak -> Lettertype -> Geavanceerd ->
> > Tekensets) en dit werkt volgens mij goed. Kan ik dit aanpassen of zie jij
> > daar nog problemen mee?
> 
> Zo te zien dateert dit uit bug 941545 en heeft die wijziging (voor en-US
> althans) een jaar geleden plaatsgevonden. Ik hou me eigenlijk niet zo bezig 
> met dat soort zaken en weet niet of het over het hoofd is gezien of dat er
> een bepaalde reden voor was, maar het lijkt ook een keuze per locale te
> zijn. Aangezien alles tegenwoordig wel UTF8 hanteert en dit zo te zien een
> standaardinstelling betreft, denk ik dat het wel kan, maar helemaal zeker
> weten doe ik het niet.

Bug kan kloppen, het was iets meer dan een jaar geleden en de keuze was inderdaad per locale. Zie ook onderstaande thread in dev.l10n:

https://groups.google.com/forum/#!searchin/mozilla.dev.l10n/send_default_charset/mozilla.dev.l10n/PH7tF9m8vUY/L1tdpuMU960J

Ik zie dat de en fr inmiddels zijn omgezet naar UTF-8, dus het lijkt me dat nl ook moet kunnen.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #144)
> 
> We kunnen er ook een kleine stoelendans van maken, want de c voor
> Accountinstellingen is best fijn en wordt door mij in ieder geval veel
> gebruikt. Chatstatus zou dan bijvoorbeld als accesskey h krijgen , Recente
> geschiedenis wissen wordt dan r (zal niet zo'n probleem zijn, omdat mensen
> sneller Ctrl+Shift+Del zullen gebruiken dan de accesskey) en Externe
> debugverbinding toestaan kan dan r worden.

Prima, lijkt me een mooie oplossing.

> Er zitten overigens nog twee fout accesskeys in dit menu: Opgeslagen
> bestanden heeft de l en Importeren heeft de i. Dit kan respectievelijk n en
> m worden.

Die l vind ik wel een probleem (=1 pixel breed), de I is dat in principe niet en conflicteert ook niet, maar Importeren heeft elders soms ook al een m. Kijk maar wat je wilt…

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #145)
> 
> Ik zie dat de en fr inmiddels zijn omgezet naar UTF-8, dus het lijkt me dat
> nl ook moet kunnen.

Inderdaad, ook geen probleem.

Mocht je nog dubbele keys tegenkomen w.b. Lightning (als je dat hebt geïnstalleerd uiteraard), hoor ik het graag.
Ik heb de accesskeys aangepast en send_default_charset gewijzigd.
Bij mij op Windows 8 is de hoofletter I van Importeren ook 1 pixel breed, dus toch maar meegenomen.
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/3a51fbea9029
Goed punt, heb niet bij andere lettertypen stilgestaan. De x gaat wel conflicteren met een extensie (ImportexExportTools gebruikt hem voor exporteren), maar dat is dan voor de extensie. Belangrijker: in Adresboek en wellicht elders wordt ook de I voor Importeren gebruikt…

Ben trouwens nog bezig met nalopen van je bijwerkactie. Niet dat er nou zo veel aan mankeert, maar het wordt wel een lange bugpost. Liever in de mail of toch in de bug?
Correctie op tb-aurora 38.0a2 n.a.v. opmerkingen Ton

Ik heb overal "Uitgaande server (SMTP)" vervangen door "Uitgaande (SMTP-)server". Die laatste vorm werd al op een paar plaatsen gebruikt, bij de account wizard. Ik heb meteen ook maar "Nieuwsserver (NNTP)" door "(NNTP-)nieuwsserver" vervangen.

http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl//rev/d3218941ed72
Attached patch authenticatiemethode.diff (obsolete) — Splinter Review
Patch naar aanleiding van opmerking van Ton met betrekking tot woordvolgorde bij "probeer dan..." en "steelt" wat te stellig is. Ik weet niet zeker of ik zo alle strings heb waar dit voorkomt, maar ik controleer het nog wel een keer als de patch toegepast is.
Wijzigingen lijken met OK, maar ik zou ze wel apart op mail en suite toepassen, dus ook niet in 1 patch op beide producten, ondanks dat dat misschien logischer lijkt als het om dezelfde wijzigingen gaat.

Ik zie onder in de patch ook nog het enige voorkomende geval van 'ingelogd' in de Kerberos-string, maar zoals bekend staan er nog wel meer fouten in. Kortom: je zou localMsg.properties van suite en mail naast elkaar kunnen leggen om de rest te vinden, net als bij overige bestanden eigenlijk.

Heb je trouwens zelf nog een controles gedaan van de submappen van mail en de overige, dus zeg maar na mijn patch deel 3? Daarin zitten waarschijnlijk nog de meeste fouten.

N.a.v. http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/9c8e9dd5d155 (voor SM) zag ik overigens nog een ontbrekende komma (voor omdat) in smtpSendInterrupted.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #134)
> (In reply to Ton from comment #133)
> > (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #132)
> > > Het opgerekte optiesvenster heb ik nog nooit gezien.

Inmiddels verholpen in bug 1124640.

(In reply to Ton from comment #143)
> … toen al had gekund/gemoeten. Ik zou het maar doen dan. Herinnert me trouwens
> aan een dubbele key voor Lightning; wellicht moet Lightning (net als andere
> extensies) daarom worden aangepast, niet andersom.

In Bestand -> Nieuw zag ik dubbele b's. Kun je daar iets aan doen, bv. de B aanpassen naar e (liefst voor Bestaande e-mailaccount)? Als je Lightning hebt geïnstalleerd, zie je daarvan ook de n in Agenda; deze wordt een d, maar kun je dan een F geven aan Feedaccount?

Een gedeelde key in menu Bewerken is de E; voor Lightning wordt dat ook een d.
Behalve Bestaande e-mailaccount en Feedaccount heb ik ook Chataccount aangepast wegens dubbele c
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/48c0bd94e1d7
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #154)
> Behalve Bestaande e-mailaccount en Feedaccount heb ik ook Chataccount
> aangepast wegens dubbele c

Ik heb Chatcontact aangepast ipv Chataccount
In reply to Onno Ekker [:nONoNonO UTC+1] from comment #154)
> > Behalve Bestaande e-mailaccount en Feedaccount heb ik ook Chataccount
> > aangepast wegens dubbele c
>>
>>  newIMContactCmd.label "Chatcontact…">
>> -newIMContactCmd.accesskey "h">
>> +newIMContactCmd.accesskey "t">

Goed gezien, maar dan was de c in Adresboekcontact (in mailOverlay) waarschijnlijk je bedoeling? Voordat je dit aanpast: een t daarin conflicteert dan met de T(aak) in Lightning. Andere mogelijkheid (r, s)?

Overigens dateert (even uit het hoofd) de c van Adresboekcontact nog uit de tijd dat het Contact was, m.a.w. deze is ouder dan die van het later ingevoerde Chatcontact. Maar dat terzijde.
(In reply to Ton from comment #156)

> Overigens dateert (even uit het hoofd) de c van Adresboekcontact nog uit de
> tijd dat het Contact was, m.a.w. deze is ouder dan die van het later
> ingevoerde Chatcontact. Maar dat terzijde.

Dat was onzin; ik bedoelde dat Chatcontact en daarmee de C later is geïntroduceerd, maar denk ik beter behouden kan blijven.
Nou, zo te zien heb ik de verkeerde c aangepast en heb ik de h van C_h_atcontact veranderd in een t. zodat we nu nog steeds twee c's hebben. Dat komt er nou van als je je patch drie keer moet terugdraaien wegens een mergeconflict. Dus Cha_t_contact maar weer terug naar de h en de c van Adresboek_c_ontact veranderd in een e.
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/72a7b913709d

Overigens komt Bestand -> Nieuw -> Adresboekcontact ook voor in het Opstellen/Nieuw bericht venster en bij het Adresboek, maar dan beide met de A, welke hier conflicteert met Andere accounts. Dus ik kan Adresboekcontact ook hier naar de A veranderen en Andere accounts naar een e, r, of s.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #158)
> Nou, zo te zien heb ik de verkeerde c aangepast en heb ik de h van
> C_h_atcontact veranderd in een t. zodat we nu nog steeds twee c's hebben.
> Dat komt er nou van als je je patch drie keer moet terugdraaien wegens een
> mergeconflict. Dus Cha_t_contact maar weer terug naar de h en de c van
> Adresboek_c_ontact veranderd in een e.
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/72a7b913709d

Dat schreef ik hierboven ook. En als je de e gebruikt, conflicteert die met de gisteren naar e gewijzigde key voor Bestaande e-mailaccount. Ik zou dus de s gebruiken (en geef de info niet voor niets ;) ).

De vergissing heeft denk ik weinig met het conflict te maken, meer met secuur werken. Het conflict wordt alleen veroorzaakt door een andere wijziging in de tree, ook al betreft die andere bestanden. Hg update van tevoren zou moeten helpen, zodat je altijd met de actuele versie werkt, en uiteraard dit soort wijzigingen lokaal eerst even testen (en/of bespreken) voordat je iets commit, wat je eigenlijk als iets definitiefs moet zien (dus niet te pas en te onpas of te snel dingen wijzigen zonder dat je zeker weet dat iets goed is, staat anders ook slordig in de logs). Je zou ook een back-up van alle gewijzigde bestanden, de map ervan of de hele tree kunnen maken voor een commit, zodat als het echt fout gaat, je vrij snel een nieuwe tree kunt gebruiken met je gewijzigde bestanden.

> Overigens komt Bestand -> Nieuw -> Adresboekcontact ook voor in het
> Opstellen/Nieuw bericht venster en bij het Adresboek, maar dan beide met de
> A, welke hier conflicteert met Andere accounts. Dus ik kan Adresboekcontact
> ook hier naar de A veranderen en Andere accounts naar een e, r, of s.

Daat zijn naar mijn weten aparte entity's, dus kun je daar gewoon de A aanhouden. Probeer altijd zo min mogelijk keys te wijzigen als het kan.
Driemaal is scheepsrecht (of was dit de vierde keer?):
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/84bad07ac19b
Ik had liever de s gebruikt (duidelijker dan de r) en noemde hem daarom de twee keer.
Ik zie dat bij menu Bericht ook de n dubbel gebruikt wordt: Nieuw bericht en Bijlagen. Nieuw bericht willen we denk ik graag zo houden, dus dat zou Bijlagen iets anders moeten worden. Daar is ook weer een stoelendans voor nodig, omdat alle andere letters al gebruikt of niet gewenst zijn. Ik stel voor bij Bijlagen de e te gebruiken en dan voor Allen beantwoorden de d.
Akkoord. Wel eerst lokaal testen graag.
Accesskeys voor Bestand->Nieuw en Bericht. Ik heb kunnen controleren, omdat mijn lokale build het eindelijk doet... 
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/2dddd793af61
Laatste verbeteringen van Ton verwerkt, typo verbeterd en tekst bij authenticatiemethode consequent doorgevoerd. http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/c9f5a2635902
Attachment #8579221 - Attachment is obsolete: true
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #166)
> 
> Nieuwe strings nav bug 1140720:
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/6a8a02e10a8c
> 
> +<!ENTITY  font.langGroup.latin          "Latin">
> +<!ENTITY  font.langGroup.other          "Andere schrijfsystemen">

Beide zijn onlangs in 'geland' in FF34 en nu dus hier. Onno merkte denk ik terecht op dat Latin wel Latijn zou kunnen worden.
Daarnaast zou ik 'Andere schriftsystemen' gebruiken; het gaat hier immers om Latijnse en andere schriften (zie ook 'lettergreepschrift). Dit wint het veruit in zoekresultaten en bij vertaalwebsites. Alleen in Win 8 zou 'schrijfsysteem' voorkomen, maar of dat juist is betwijfel ik ten zeerste.
Beide gelden voor TB en FF.

> Accountwizard:
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/79cac2cdf365
> 
> -<!ENTITY accountManager.size "width: 107ch; height: 49em;">
> +<!ENTITY accountManager.size "width: 117ch; height: 55em;">
> -<!ENTITY purge2.label "dagen automatisch uit deze map verwijderen">
> +<!ENTITY purge2.label "dagen automatisch verwijderen">

De gebruikte waarden (117 en 55) leveren bij testen in Win 7 een venster Accountinstellnigen op dat bij openen ervan nèt geen scrollbalken heeft, met name belangrijk omdat de venstergrootte na vergroten/verkleinen ervan niet wordt onthouden. De inkorting was handig om het venster niet te breed te hoeven maken, maar "uit deze map" bleek ook al niet in en-US te staan.

De vraag is wat de invloed m.b.t. het venster Accountinstellingen is in Linux, Mac en andere Windows-versies. Kan iemand dit testen?
Attached patch Fix voor reply-header verwijderd (obsolete) — Splinter Review
De noodoplossing voor de woordvolgorde van de reply-header (zie comment 7) is na bug 995797 niet meer nodig. Het kan weliswaar geen kwaad omdat de extra entitty niet meer wordt gebruikt en de andere is verwijderd, maar geeft wel rommel/verwarring en het standaardtype is nog steeds 3 voor NL, terwijl 2 nu ook goed werkt. Het lijkt me wel zo netjes de aanpassing terug te draaien, met als enige gevolg dat bij een update het standaardtype vanzelf type 2 en daarmee "Op <datum> om <tijd> schreef Piet:" zal worden i.p.v. nu "Piet schreef op <datum> om <tijd>:". Gezien de feedback van gebruikers destijds lijkt de vorm van type 2 toch al de voorkeur te hebben, en anders kunnen gebruikers het zelf aanpassen naar type 3 in about:config of met een extensie zolang dit nog niet in de UI kan.
Accountmanager moest toch nog wat groter voor Windows 8. Nu past hij bij mij op alle platformen.
Ook fonts.dtd verbeterd.
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/ef4bf5b4e6fa
(In reply to Ton from comment #168)
> Created attachment 8583776 [details] [diff] [review]
> Fix voor reply-header verwijderd
Toegepast: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/6db04218640c
Attachment #8583776 - Attachment is obsolete: true
Inclusief wat andere aangetroffen zaken.
Zoals per mail gemeld aan Onno wilde ik graag alle dubbele aanhalingstekens vervangen door enkele, omdat dubbele i.t.t. in het Engels alleen worden gebruikt bij citaten, en tegenwoordig zelfs dan niet meer altijd - zie https://onzetaal.nl/taaladvies/advies/enkele-aanhalingstekens en http://taaladvies.net/taal/advies/vraag/11/dubbele_of_enkele_aanhalingstekens_bij_een_citaat/). Voor overige producten en webpagina’s kunnen we dat dus ook geleidelijk invoeren. Alleen gekrulde uiteraard, en ook waar en-US &quot; hanteert.

De patch vervangt de dubbele overal door enkele in \mail. Ook een gevalletje van ‘bestaat al’ en enkele van ‘Antwoorden aan’ (->op) meegenomen.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #175)
> TB 39.0a2 is klaar voor controle:
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/38698374b82a

diff --git a/mail/chrome/messenger/am-server-top.dtd b/mail/chrome/messenger/am-server-top.dtd
-<!ENTITY serverDefaultCharset.label "Standaard tekenset:">
+<!ENTITY serverDefaultCharset2.label "Standaard tekstcodering:">

Niet dat ik het echt fout vind, maar strings met ‘encoding’ verdienen wat extra aandacht. In bug 305315 heeft een uitvoerige discussie over het begrip ‘character encoding’ plaatsgevonden, vandaar de oude vorm (tekenset). Voor het Engelse ‘text encoding’ lijkt ‘tekstcodering’ wel in orde, maar een zekere softwarefabrikabnt die dat doet hanteert ook ‘tekencodering’ voor ‘character encoding’, en daar was Laurens het in bug 305315 comment 132 volledig mee oneens, dus ik kan me een soortgelijk idee hierover voorstellen.
Daarnaast zag ik dat de bug die deze wijziging initieerde (bug 951695) is ingediend door Anne, die in het verleden ook aan de NL-vertalingen heeft bijgedragen. Dat is niet zo relevant maar ik vind de argumenten erin niet zo sterk, ook van anderen (lees: gaan we andere browsers nadoen, staat het mooier of is het korter, of is er echt sprake van een onjuiste term in het verleden en zo ja, alleen in en-US of in alle talen?). Ik weet niet of Laurens de NL-bugs nog volgt, maar hij zal vast een mening over deze wijziging hebben en het zou me niet verbazen als hij ervoor pleit de oude term te blijven hanteren. Persoonlijk denk ik dat tekstcodering wel geoorloofd is.

diff --git a/mail/chrome/messenger/folderProps.dtd b/mail/chrome/messenger/folderProps.dtd
Niet ernstig, maar in regel 18 in en-US zijn spaties verwijderd; dit zou ik dan ook doen in nl om geen verwarring te geven bij vergelijken. Goed voorbeeld van iets wat alleen zichtbaar is zonder het dashboard.

diff --git a/mail/chrome/messenger/messenger.dtd b/mail/chrome/messenger/messenger.dtd
+<!ENTITY sortByCorrespondentCmd.label "Correspondenten">
+<!ENTITY sortByCorrespondentCmd.accesskey "e">

Je zult wel hebben gemerkt dat de keys in dit menu op lijken en de e al wordt gebruikt, evenals de v die dubbel is. De f, h, j, k en m zijn echter nog vrij, waarbij j en k afvallen. De i zou vanwege de 1 pixelbreedte denk ik wel een h kunnen worden, de m kan alleen in Datum (de d komt dan vrij), de f alleen in Aflopend en levert de a op (jammer voor O en A voor Oplopend en Aflopend, ooit bewust zo gekozen). De d en a kunnen dan respectievelijk in Correspondenten en Ontvangen. Als de O van Oplopend ook geen O meer hoeft te zijn vanwege de gewijzigde A voor Aflopend, kan dat de d worden en de o voor Correspondenten worden gebruikt (lichte voorkeur).
Daarnaast nog een erg oud foutje gespot: groupBySort.label zal zeer waarschijnlijk ‘op sortering’ moeten gebruiken i.p.v. ‘op soort’.

diff --git a/mail/chrome/messenger/preferences/fonts.dtd b/mail/chrome/messenger/preferences/fonts.dtd
-<!ENTITY languagesTitle1.label            "Tekensets">
-<!ENTITY composingDescription.label       "Standaard tekensets voor verzenden en ontvangen van e-mailberichten">
+<!ENTITY languagesTitle2.label            "Tekstcodering">
+<!ENTITY composingDescription2.label      "Standaard tekencodering voor verzenden en ontvangen van e-mailberichten instellen">

In composingDescription2.label zul je ‘tekstcodering’ bedoelen. En nu je er toch bent: ik zou hier ‘De standaard tekstcodering...’ gebruiken (+De). Engels gebruikt ook ‘Use the’, wat misschien niet belangrijk lijkt, maar het weglaten van ‘de’ in het NL zorgt ervoor dat het lijkt alsof de hele actie standaard is i.p.v. dat ‘standaard’ bij de tekstcodering hoort (als in ‘Standaard de tekstcodering...’).
Overigens is los of vast schrijven van ‘standaard’ aan het zelfstandig naamwoord afhankelijk van de klemtoon (dus ‘een stándaardcodering’, maar ‘een standaard tékencodering’), vaak automatisch resulterend in los schrijven van ‘standaard’ bij langere combinaties.

 <!ENTITY viewDefaultCharsetList.label     "Inkomende e-mailberichten:">
 <!ENTITY viewDefaultCharsetList.accesskey "I">
-<!ENTITY replyInDefaultCharset2.label     "Wanneer mogelijk, de standaard tekenset gebruiken in antwoorden">
-<!ENTITY replyInDefaultCharset2.accesskey "W">
+<!ENTITY replyInDefaultCharset3.label     "Wanneer mogelijk  in antwoorden de standaard tekstcodering gebruiken">
+<!ENTITY replyInDefaultCharset3.accesskey "W">

Afgezien van het spatiefoutje in replyInDefaultCharset3.label zie ik niet waarom de komma in deze zin moet verdwijnen en het naar voren verplaatsen van ‘in antwoorden’ zou moeten of beter is.
Verder kan de bestaande I erboven eventueel een andere key krijgen (k?). Keys als de n voor Minimale (en eigenlijk ook die van Grootte) zou ik liefst hetzelfde houden als in FF, vandaar geen n.
Onno, beschouw jij /chat als onderdeel van TB? Zo ja, dan blijf ik ervan af bij het bijwerken van de gezamenlijke mappen. Zo nee, laat het dan even weten.
Ik heb toen ik net begon met vertalen in deze bug een bestand van chat meegenomen (comment 91), maar het hoort bij bug 1064769. Je mag het dus vertalen! :-)
(In reply to Ton from comment #176)
> (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #175)
> > TB 39.0a2 is klaar voor controle:
> > http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/38698374b82a
> 
> diff --git a/mail/chrome/messenger/am-server-top.dtd
> b/mail/chrome/messenger/am-server-top.dtd
> -<!ENTITY serverDefaultCharset.label "Standaard tekenset:">
> +<!ENTITY serverDefaultCharset2.label "Standaard tekstcodering:">
> 
> Niet dat ik het echt fout vind, maar strings met ‘encoding’ verdienen wat
> extra aandacht. In bug 305315 heeft een uitvoerige discussie over het begrip
> ‘character encoding’ plaatsgevonden, vandaar de oude vorm (tekenset). Voor
> het Engelse ‘text encoding’ lijkt ‘tekstcodering’ wel in orde, maar een
> zekere softwarefabrikabnt die dat doet hanteert ook ‘tekencodering’ voor
> ‘character encoding’, en daar was Laurens het in bug 305315 comment 132
> volledig mee oneens, dus ik kan me een soortgelijk idee hierover voorstellen.
> Daarnaast zag ik dat de bug die deze wijziging initieerde (bug 951695) is
> ingediend door Anne, die in het verleden ook aan de NL-vertalingen heeft
> bijgedragen. Dat is niet zo relevant maar ik vind de argumenten erin niet zo
> sterk, ook van anderen (lees: gaan we andere browsers nadoen, staat het
> mooier of is het korter, of is er echt sprake van een onjuiste term in het
> verleden en zo ja, alleen in en-US of in alle talen?). Ik weet niet of
> Laurens de NL-bugs nog volgt, maar hij zal vast een mening over deze
> wijziging hebben en het zou me niet verbazen als hij ervoor pleit de oude
> term te blijven hanteren. Persoonlijk denk ik dat tekstcodering wel
> geoorloofd is.

Naar aanleiding van discussie in bug 305315 en voortschrijdend inzicht toch weer terug naar tekenset.

> ...
>
> diff --git a/mail/chrome/messenger/messenger.dtd
> b/mail/chrome/messenger/messenger.dtd
> +<!ENTITY sortByCorrespondentCmd.label "Correspondenten">
> +<!ENTITY sortByCorrespondentCmd.accesskey "e">
> 
> Je zult wel hebben gemerkt dat de keys in dit menu op lijken en de e al
> wordt gebruikt, evenals de v die dubbel is. De f, h, j, k en m zijn echter
> nog vrij, waarbij j en k afvallen. De i zou vanwege de 1 pixelbreedte denk
> ik wel een h kunnen worden, de m kan alleen in Datum (de d komt dan vrij),
> de f alleen in Aflopend en levert de a op (jammer voor O en A voor Oplopend
> en Aflopend, ooit bewust zo gekozen). De d en a kunnen dan respectievelijk
> in Correspondenten en Ontvangen. Als de O van Oplopend ook geen O meer hoeft
> te zijn vanwege de gewijzigde A voor Aflopend, kan dat de d worden en de o
> voor Correspondenten worden gebruikt (lichte voorkeur).

Ik heb Datum naar de m veranderd, zodat de d vrij kwam voor Correspondenten.
De i van Ongewenstberichtstatus is een h geworden.
Aflopend is nu een f, zodat de a vrij kwam voor Ontvangen.
Wou jij nou de accesskeys O en d van Oplopend en Correspondenten omgewisseld hebben? Waarom? Volgens mij is het zo duidelijker, met ten minste 1 een accesskey aan het begin van een woord.

> ...
> 
>  <!ENTITY viewDefaultCharsetList.label     "Inkomende e-mailberichten:">
>  <!ENTITY viewDefaultCharsetList.accesskey "I">
> -<!ENTITY replyInDefaultCharset2.label     "Wanneer mogelijk, de standaard
> tekenset gebruiken in antwoorden">
> -<!ENTITY replyInDefaultCharset2.accesskey "W">
> +<!ENTITY replyInDefaultCharset3.label     "Wanneer mogelijk  in antwoorden
> de standaard tekstcodering gebruiken">
> +<!ENTITY replyInDefaultCharset3.accesskey "W">
> 
> Afgezien van het spatiefoutje in replyInDefaultCharset3.label zie ik niet
> waarom de komma in deze zin moet verdwijnen en het naar voren verplaatsen
> van ‘in antwoorden’ zou moeten of beter is.

Ik dacht dat http://taaladvies.net/taal/advies/vraag/460 hier op van toepassing was en woordvolgorde leek me mooier, maar heb ik weer hersteld.

> Verder kan de bestaande I erboven eventueel een andere key krijgen (k?).
> Keys als de n voor Minimale (en eigenlijk ook die van Grootte) zou ik liefst
> hetzelfde houden als in FF, vandaar geen n.

Als ik de accesskey van de 2e Grootte in o verander, net als in Firefox, kan ik de e gebruiken voor Inkomende e-mailberichten.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #179)
> 
> Naar aanleiding van discussie in bug 305315 en voortschrijdend inzicht toch
> weer terug naar tekenset.

Oei, misschien hier nog even mee wachten? Ik heb Tekstcodering nu ook in de gezamenlijke mappen aangehouden en ben eigenlijk benieuwd naar de mening van Laurens, dus wilde hem gaan mailen. Mee eens?

> > diff --git a/mail/chrome/messenger/messenger.dtd
> > b/mail/chrome/messenger/messenger.dtd
> > +<!ENTITY sortByCorrespondentCmd.label "Correspondenten">
> > +<!ENTITY sortByCorrespondentCmd.accesskey "e">
> > 
> 
> Ik heb Datum naar de m veranderd, zodat de d vrij kwam voor Correspondenten.
> De i van Ongewenstberichtstatus is een h geworden.
> Aflopend is nu een f, zodat de a vrij kwam voor Ontvangen.
> Wou jij nou de accesskeys O en d van Oplopend en Correspondenten omgewisseld
> hebben? Waarom? Volgens mij is het zo duidelijker, met ten minste 1 een
> accesskey aan het begin van een woord.

Tja, de O en A werden beide voor Oplopend en Aflopend gebruikt en stonden dus vooraan in deze ‘sectie’ met 2 opties, wat mooier lijkt dan dat dit bij slechts één ervan gebeurt. Daarbij is, van boven naar beneden in het menu gezien, het iets logischer om keys wat meer vooraan te plaatsten, vandaar de o als de C al bezet is. Dat de d dan in Oplopend wel erg achteraan komt vergeleken met de f in Aflopend is natuurlijk ook wel zo (eigenlijk was de p wel wenselijk), maar dit leek me minder belangrijk.

> >  <!ENTITY viewDefaultCharsetList.label     "Inkomende e-mailberichten:">
> >  <!ENTITY viewDefaultCharsetList.accesskey "I">
> > -<!ENTITY replyInDefaultCharset2.label     "Wanneer mogelijk, de standaard
> > tekenset gebruiken in antwoorden">
> > 
> Ik dacht dat http://taaladvies.net/taal/advies/vraag/460 hier op van
> toepassing was en woordvolgorde leek me mooier, maar heb ik weer hersteld.

Ik hou wel van dat soort aangehaalde bronnen :) en weet niet in welk taalstraatje het moet passen (wellicht is het voorbeeld in (4) het meest geschikt), maar het eerste deel heeft dan wel dezelfde tijdfactor en geen deelwoord, het probleem is dat het tweede onbepaald is (door ‘gebruiken’). Je kunt het ook zo lezen:
‘Als het mogelijk is, de standaard tekstcodering gebruiken’ - hierin is dan wel verschil van tijd zichtbaar.
Een voorbeeld van een dito zin die verwarring zou geven:
‘Wanneer mogelijk de standaard tekenset wordt gebruikt, kan dit blabla...’
Daarin is te zien dat weglaten van de komma tot heel anders lezen van de zin leidt, toch?
Kort gezegd: de rustpauze is nodig, en je hoort hem ook. Ik weet het niet zeker, maar mogelijk is deze komma in het verleden ook al eens besproken.

> > Verder kan de bestaande I erboven eventueel een andere key krijgen (k?).
> > Keys als de n voor Minimale (en eigenlijk ook die van Grootte) zou ik liefst
> > hetzelfde houden als in FF, vandaar geen n.
> 
> Als ik de accesskey van de 2e Grootte in o verander, net als in Firefox, kan
> ik de e gebruiken voor Inkomende e-mailberichten.

Lijkt me een prima oplossing.

Kun je trouwens Chatroom aanpassen naar Chatruimte (2 x in joinchat.dtd)? Viel me gisteren op dat dit het enige geval is van room en in comment 60 pleitte je hier zelf voor.
Wegens nog nieuwer inzicht, ruggespraak buiten de bug om met Laurens, vergelijk met Duits en Frans, vergelijk met Safari en Internet Explorer en omdat er eigenlijk geen bezwaar lijkt te zijn tegen tekstcodering toch besloten om dit begrip in het Nederlands in te voeren. Dat maakt het ook makkelijker bij gebruikersproblemen, omdat dan direct duidelijk is dat het op zijn Engels om de text encoding gaat...

http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/2e7a5e0ddc31
Attached patch Klemtonen en consistenties (obsolete) — Splinter Review
Dingetjes die uit recente wijzigingen in FF en gezamenlijk zijn gerold.

Let op: bij bv. ‘en nog x’ kan op bepaalde plaatsen eventueel ook worden gekozen voor iets als ‘en x anderen’.
Comment on attachment 8585183 [details] [diff] [review]
Controle TB vanaf 26-04-12 deel 4 (laatste) e.a.

Toegepast 2015-03-30 (zie comment 174)
Attachment #8585183 - Attachment is obsolete: true
Comment on attachment 8585481 [details] [diff] [review]
Dubbele -> enkele aanhalingstekens

Toegepast 2015-03-30 (zie comment 174)
Attachment #8585481 - Attachment is obsolete: true
Comment on attachment 8600847 [details] [diff] [review]
Klemtonen en consistenties

Patch toegepast: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/372aaacbebe1
Attachment #8600847 - Attachment is obsolete: true
Attached patch Invoeren / niet-toegestane (obsolete) — Splinter Review
Gemist in de vorige.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #188)
> Thunderbird 40.0a2 is klaar voor controle:
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/01712594cea0

Ik zie 2 nieuwe regels in het Engels (smtpSendRequestRefused en smtpAuthenticationNotSupported). Verder ook een rechte apostrof (zie dit als ‘absouluut verboden’), en ‘site’ vertalen we nagenoeg altijd als ‘website’ (zie het vertaalwordenboek). ‘Ongewenste softwarepagina’s’ zijn softwarepagina’s die ongewenst zijn, wat dus niet juist is. Hier hebben we het als eens over gehad (gevalletje langeafstandsloper/hogesnelheidslijn). Om die reden heb ik deze term (met ‘site’) in Sumo vertaald als ‘Websites met ongewenste software’ i.p.v. ‘ongewenstesoftwarewebsite’; zie ‘Hoe werkt ingebouwde bescherming tegen phishing en malware?’.
(In reply to Ton from comment #189)
> Ik zie 2 nieuwe regels in het Engels (smtpSendRequestRefused en
> smtpAuthenticationNotSupported). Verder ook een rechte apostrof (zie dit als
> ‘absouluut verboden’), en ‘site’ vertalen we nagenoeg altijd als ‘website’
> (zie het vertaalwordenboek). ‘Ongewenste softwarepagina’s’ zijn
> softwarepagina’s die ongewenst zijn, wat dus niet juist is. Hier hebben we
> het als eens over gehad (gevalletje langeafstandsloper/hogesnelheidslijn).
> Om die reden heb ik deze term (met ‘site’) in Sumo vertaald als ‘Websites
> met ongewenste software’ i.p.v. ‘ongewenstesoftwarewebsite’; zie ‘Hoe werkt
> ingebouwde bescherming tegen phishing en malware?’.

Sorry, ik had het natuurlijk beter moeten controleren, maar ik snap niet hoe die Engelse zinnen er in zijn gekomen. Ik heb ze nota bene nog gebruikt voor de vertaling van SeaMonkey.

http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/1c222519de74
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #196)
> TB Aurora 43.0a2 is klaar voor controle:
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/5d4df555c574
> 
> +++ b/mail/chrome/messenger/aboutDownloads.dtd
> 
> -<!ENTITY cmd.clearDownloads.label                  "Downloads wissen">
> -<!ENTITY cmd.clearDownloads.accesskey              "w">
> +<!ENTITY cmd.clearList.label                       "Lijst wissen">
> +<!ENTITY cmd.clearList.accesskey                   "L">

Ik ben bang dat de L met de knop en in het menu wordt gedeeld, en in de knop conflicteert met die in menu Beeld, wellicht dat deze daarom ook w was bij Downloads. Alt-D dienen we overigens ook te vermijden, omdat dat in browser een sneltoets is voor de adresbalk (zie vertaalwoordenboek) en misschien ook in TB problemen kan geven, zo uit het hoofd.

> +<!ENTITY cmd.clearList.tooltip                     "Alle vermeldingen uit de lijst van bewaarde bestanden verwijderen, behalve de lopende downloads.">

‘Saved’ vertalen we altijd als ‘opgeslagen’, en ‘stored’ _soms_ als ‘bewaard’. Ook heb ik geen goed gevoel bij ’lopende’ - dit is spreektaal (net als een ‘draaiende’ computer) en geen nette vertaling. Liever ‘actieve’; dit is tot nu toe ook 1 keer over het hoofd gezien in Browser. Verder niet ernstig, maar ik zou ‘de’ (bij actieve downloads) net als in en-US weglaten.
Tooltips eindigen in de regel ook nooit met een punt, uitzonderingen (zoals bij meerdere zinnen) daargelaten, of als het een omschrijving is in derde persoon (Opent de … in een nieuw venster.) en dan nog is het omstreden. Terugkijkend naar bug 1152743 voor deze wijziging blijkt dit een slordigheidje te zijn (zie ook mijn reactie daarin), en ik zou er daarom hier (vast) ‘Verwijdert alle vermeldingen uit de lijst van opgeslagen bestanden, behalve actieve downloads’ van maken.

> +++ b/mail/chrome/messenger/prefs.properties
> 
> +removeFromServerTitle=Permanent, automatisch verwijderen van berichten bevestigen
> +removeFromServer=Met deze instelling zullen oude berichten permanent van de server EN uit uw lokale opslag verwijderd worden. Weet u zeker dat u wilt doorgaan?

Ik heb wat moeite met ‘permanent’; dit stond eerder op een todolijst en is tot nu toe in TB zo gebleven. Misschien daar eens apart naar kijken, en als het kan ‘voorgoed’, ‘blijvend’ of ‘voor altijd’ gebruiken (zie overige bestanden). Ik mis ook ‘externe’ (server).
Met ‘storage’ wordt doorgaans opslag bedoeld, maar soms is een opslagmedium beter. Ik weet niet wat hier beter is, het kan denk ik wel opslag blijven.
‘Verwijderd worden’ is uit den boze en nu waarschijnlijk het enige geval in de tree. Zoals eerder vermeld (o.a. in bug 1064769), dienen we bij deelwoordconstructies vormen van hebben, worden en zijn vóóraan te plaatsen (rode volgorde), dus ‘worden verwijderd’. 

Ik zag ook nog een ‘Laatste 5 dagen’ in mailViewLastFiveDays. Ik kon niet vinden waar deze voorkomt, maar kun je hier omwille van consistentie en na controle ervan ‘Afgelopen…’ van maken?
(In reply to Ton from comment #197)
> (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #196)
> > TB Aurora 43.0a2 is klaar voor controle:
> > http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/5d4df555c574
> > 
> > +++ b/mail/chrome/messenger/aboutDownloads.dtd
> > 
> > -<!ENTITY cmd.clearDownloads.label                  "Downloads wissen">
> > -<!ENTITY cmd.clearDownloads.accesskey              "w">
> > +<!ENTITY cmd.clearList.label                       "Lijst wissen">
> > +<!ENTITY cmd.clearList.accesskey                   "L">
> 
> Ik ben bang dat de L met de knop en in het menu wordt gedeeld, en in de knop
> conflicteert met die in menu Beeld, wellicht dat deze daarom ook w was bij
> Downloads. Alt-D dienen we overigens ook te vermijden, omdat dat in browser
> een sneltoets is voor de adresbalk (zie vertaalwoordenboek) en misschien ook
> in TB problemen kan geven, zo uit het hoofd.

Je hebt gelijk, alleen wordt de w ook gedeeld met be_w_erken... Alt-D kan niet, want er zit geen d in Lijst wissen. Dan hou je de S, T en N over. Voorkeur?

> 
> > +<!ENTITY cmd.clearList.tooltip                     "Alle vermeldingen uit de lijst van bewaarde bestanden verwijderen, behalve de lopende downloads.">
> 
> ‘Saved’ vertalen we altijd als ‘opgeslagen’, en ‘stored’ _soms_ als
> ‘bewaard’. Ook heb ik geen goed gevoel bij ’lopende’ - dit is spreektaal
> (net als een ‘draaiende’ computer) en geen nette vertaling. Liever
> ‘actieve’; dit is tot nu toe ook 1 keer over het hoofd gezien in Browser.
> Verder niet ernstig, maar ik zou ‘de’ (bij actieve downloads) net als in
> en-US weglaten.

De enige andere plaats waar ‘ongoing downloads’ voor komt, is dit ook vertaald met ‘lopende downloads’. Zal ik ze dan allebei maar in ‘actieve downloads’ veranderen?

> Tooltips eindigen in de regel ook nooit met een punt, uitzonderingen (zoals
> bij meerdere zinnen) daargelaten, of als het een omschrijving is in derde
> persoon (Opent de … in een nieuw venster.) en dan nog is het omstreden.
> Terugkijkend naar bug 1152743 voor deze wijziging blijkt dit een
> slordigheidje te zijn (zie ook mijn reactie daarin), en ik zou er daarom
> hier (vast) ‘Verwijdert alle vermeldingen uit de lijst van opgeslagen
> bestanden, behalve actieve downloads’ van maken.

De tooltips die ik zo 1-2-3 kan vinden, gebruiken allemaal de vorm ‘…verwijderen…’. Waarom stel je hier ‘verwijdert’ voor?

> > +++ b/mail/chrome/messenger/prefs.properties
> > 
> > +removeFromServerTitle=Permanent, automatisch verwijderen van berichten bevestigen
> > +removeFromServer=Met deze instelling zullen oude berichten permanent van de server EN uit uw lokale opslag verwijderd worden. Weet u zeker dat u wilt doorgaan?
> 
> Ik heb wat moeite met ‘permanent’; dit stond eerder op een todolijst en is
> tot nu toe in TB zo gebleven. Misschien daar eens apart naar kijken, en als
> het kan ‘voorgoed’, ‘blijvend’ of ‘voor altijd’ gebruiken (zie overige
> bestanden). Ik mis ook ‘externe’ (server).

‘Remote server’ is bijna altijd vertaald met ‘server’. Moet dit dan steeds ‘externe server’ worden?

> Met ‘storage’ wordt doorgaans opslag bedoeld, maar soms is een opslagmedium
> beter. Ik weet niet wat hier beter is, het kan denk ik wel opslag blijven.
> ‘Verwijderd worden’ is uit den boze en nu waarschijnlijk het enige geval in
> de tree. Zoals eerder vermeld (o.a. in bug 1064769), dienen we bij
> deelwoordconstructies vormen van hebben, worden en zijn vóóraan te plaatsen
> (rode volgorde), dus ‘worden verwijderd’. 
> 
> Ik zag ook nog een ‘Laatste 5 dagen’ in mailViewLastFiveDays. Ik kon niet
> vinden waar deze voorkomt, maar kun je hier omwille van consistentie en na
> controle ervan ‘Afgelopen…’ van maken?

Optie is alleen beschikbaar als je de widget E-mailweergaven in de E-mailwerkbalk hebt staan. Dan stata hij daar en in het menu Beeld -> Berichten -> Aangepaste weergaven -> Laatste 5 dagen.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #198)

> Je hebt gelijk, alleen wordt de w ook gedeeld met be_w_erken... Alt-D kan
> niet, want er zit geen d in Lijst wissen. Dan hou je de S, T en N over.
> Voorkeur?

Inderdaad.. Alt-D was ook geen optie, noemde het alleen op vanwege de eerdere w. Ik zou de s kiezen.

> De enige andere plaats waar ‘ongoing downloads’ voor komt, is dit ook
> vertaald met ‘lopende downloads’. Zal ik ze dan allebei maar in ‘actieve
> downloads’ veranderen?

Daar verwees ik hierboven naar en die wilde ik meenemen in de komende nits voor browser.

> De tooltips die ik zo 1-2-3 kan vinden, gebruiken allemaal de vorm
> ‘…verwijderen…’. Waarom stel je hier ‘verwijdert’ voor?

Tooltips horen inderdaad die vorm te hebben. Zie de genoemde bug en link naar mxr voor de reden om dit anders te doen (oftewel https://transvision.mozfr.org/?recherche=cmd.clearList.tooltip&repo=aurora&sourcelocale=en-US&locale=nl&search_type=entities).

> ‘Remote server’ is bijna altijd vertaald met ‘server’. Moet dit dan steeds
> ‘externe server’ worden?

Eigenlijk wel. Het is voor thuisgebruikers op zich logisch dat een server extern is, maar in het Engels wordt het niet voor niets vermeld.

> Optie is alleen beschikbaar als je de widget E-mailweergaven in de
> E-mailwerkbalk hebt staan. Dan stata hij daar en in het menu Beeld ->
> Berichten -> Aangepaste weergaven -> Laatste 5 dagen.

Ha kijk. Afgelopen lijkt hier te passen.
> +removeFromServerTitle=Voorgoed, automatisch verwijderen van berichten bevestigen
> +removeFromServer=Met deze instelling zullen oude berichten voorgoed van de externe server EN uit uw lokale opslag worden verwijderd. Weet u zeker dat u wilt doorgaan?

Als ik het zo aanpas, dan denk ik dat ik de komma beter kan weglaten tussen Voorgoed en automatisch.
En ik heb ‘EN’ overgenomen uit het Engels, maar het is misschien beter om hier ‘én’ van te maken om de klemtoon aan te geven.
Mee eens?
EN moet inderdaad én worden.
Zou je wel komma's willen gebruiken in andere bestanden bijvoorbeeld chat/xmpp.properties:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/b661f0c9ccc4#l3.17
waar consequent geen komma staat voor het woord "omdat".
Kk had die komma daar in eerste instantie niet gebruikt, maar heb dat aangepast na Ton's controle: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/e62f92850e47#l1.19
Moet de komma in removeFromServerTitle toch ook blijven staan of kan die wel weg, of moeten we daarvoor even op Ton wachten?
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #200)
> > +removeFromServerTitle=Voorgoed, automatisch verwijderen van berichten bevestigen
> > +removeFromServer=Met deze instelling zullen oude berichten voorgoed van de externe server EN uit uw lokale opslag worden verwijderd. Weet u zeker dat u wilt doorgaan?
> 
> Als ik het zo aanpas, dan denk ik dat ik de komma beter kan weglaten tussen
> Voorgoed en automatisch.
> En ik heb ‘EN’ overgenomen uit het Engels, maar het is misschien beter om
> hier ‘én’ van te maken om de klemtoon aan te geven.
> Mee eens?
(In reply to Wim from comment #201)
> EN moet inderdaad én worden.

Waarom zou én beter zijn dan EN? Het maakt denk ik niet veel uit; beide komen nog niet voor. Echter…

(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #202)
> Kk had die komma daar in eerste instantie niet gebruikt, maar heb dat
> aangepast na Ton's controle:
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/e62f92850e47#l1.19
> Moet de komma in removeFromServerTitle toch ook blijven staan of kan die wel
> weg, of moeten we daarvoor even op Ton wachten?

Als ik nog even naar de Engelse vorm kijk:
- removeFromServerTitle=Confirm permanent, automatic deletion of messages

Het gaat hier om het blijvend ‘en’ automatisch verwijderen, en permanent betekent ook ‘definitief ’. Wat te zeggen van‘Definitieve automatische verwijdering van berichten bevestigen’? Dan is de komma inderdaad ook wat overbodig. Door ‘verwijdering’ te behouden i.p.v. verwijderen te gebruiken voorkom je ook dat je ‘definitief automatisch’ moet gebruiken, m.a.w. dat de uitgangen hiervan daarop moeten worden aangepast en de komma nodig lijkt.

Wat de andere zin betreft: ‘This setting will permanently delete old messages from the remote server AND your local storage.’

Ik zou de huidige vorm behouden en dus niet naar leidende vorm ombouwen, dus iets als ‘Deze instelling verwijdert oude berichten definitief van de externe server en uit uw lokale opslag.’, of iets met ‘zowel … als’, en de klemtoon wordt hiermee wellicht ook overbodig.

Wat ’omdat’ betreft (algemeen): in de regel gaat daar wel een komma aan vooraf, doorgaans als erachter een verklaring volgt, maar dus niet altijd. Denk maar aan ‘ik kom niet omdat ik het leuk vind’ - vaak kun je bij ontkenningen de vraag stellen ‘waarom dan wel?’.
Correcties op TB43.0a2 n.a.v. opmerkingen Ton: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/0e04e3f048e1
Ik had removeFromServer in eerste instantie omgebouwd naar de leidende vorm, omdat die instelling niet zelf die berichten verwijdert, maar dat maakt de zin wel weg gecompliceerd. Dus toch maar gewoon letterlijk vertaald…
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #205)
> TB Aurora 44.0a2 is klaar voor controle:
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/375e8d1b788b

> +++ b/mail/chrome/messenger-region/region.properties
Wijzigingen in dit bestand moeten altijd via flod. Ik zou het even navragen of dit in orde is, zowel qua toevoegingen als omzetten van .com naar .nl.

> +++ b/mail/chrome/messenger/am-advanced.dtd
> +<!ENTITY serverDetails.label "Details van geselecteerde server:">
Details gaan doorgaans ‘over’ iets (zie mxr).

> +++ b/mail/chrome/messenger/preferences/permissions.dtd
OK, maar het viel me op dat de afmetingen nogal kein zijn (36; en-US: 45). Misschien t.z.t. aanpassen?
 
> +++ b/mail/chrome/messenger/preferences/preferences.properties
> +canAccessFirstParty=Alleen directe toestaan
Hiervoor is in Firefox ‘Van derden blokkeren’ gebruikt, als ik me niet vergis om het wat ongelukkige ‘first-party’ (en dus ‘directe’) te vermijden.
(In reply to Ton from comment #206)
> > +++ b/mail/chrome/messenger-region/region.properties
> Wijzigingen in dit bestand moeten altijd via flod.

Sorry, Fallen voor TB en Callek voor SM.
(In reply to Ton from comment #206)
> (In reply to Onno Ekker [:nONoNonO UTC+1] from comment #205)
> > TB Aurora 44.0a2 is klaar voor controle:
> > http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/375e8d1b788b
> 
> > +++ b/mail/chrome/messenger-region/region.properties
> Wijzigingen in dit bestand moeten altijd via flod. Ik zou het even navragen
> of dit in orde is, zowel qua toevoegingen als omzetten van .com naar .nl.
> 
> > +++ b/mail/chrome/messenger/am-advanced.dtd
> > +<!ENTITY serverDetails.label "Details van geselecteerde server:">
> Details gaan doorgaans ‘over’ iets (zie mxr).

‘Details about’ is meestal met ‘details over’ vertaald, ‘details of’ doorgaans met ‘details of’ voor zover ik kan zien. Heb je anders een link in mxr/dxr voor me, zodat ik kan zien wat je bedoelt? Of bedoel je transvision?

> 
> > +++ b/mail/chrome/messenger/preferences/permissions.dtd
> OK, maar het viel me op dat de afmetingen nogal kein zijn (36; en-US: 45).
> Misschien t.z.t. aanpassen?

Voor zover ik kan zien zijn de schermen voor uitzonderingen voor externe inhoud en voor cookies groot genoeg, zowel voor de tekst als voor de URL's.
>  
> > +++ b/mail/chrome/messenger/preferences/preferences.properties
> > +canAccessFirstParty=Alleen directe toestaan
> Hiervoor is in Firefox ‘Van derden blokkeren’ gebruikt, als ik me niet
> vergis om het wat ongelukkige ‘first-party’ (en dus ‘directe’) te vermijden.

Ja, dat is een stuk mooier. 
https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/8c9b744af34a
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #208)
> 
> ‘Details about’ is meestal met ‘details over’ vertaald, ‘details of’
> doorgaans met ‘details of’ voor zover ik kan zien. Heb je anders een link in
> mxr/dxr voor me, zodat ik kan zien wat je bedoelt? Of bedoel je transvision?

Eens, de meeste gevallen van ‘details of’ zijn met ‘details van’ vertaald. Ik bedoelde inderdaad Transvision; als je het daarin invult, zie je twee gevallen waarin wel ‘over’ is gebruikt, gewoon omdat dat in die context beter is, en dat zat even in mijn hoofd. Maar hier wel OK.

> > > +++ b/mail/chrome/messenger/preferences/permissions.dtd
> Voor zover ik kan zien zijn de schermen voor uitzonderingen voor externe
> inhoud en voor cookies groot genoeg, zowel voor de tekst als voor de URL's.

Teksten zijn in de NL-versies doorgaans (zo’n 30%) groter dan die in en-US en soms dus ook schermen, zelden of nooit kleiner. Meestal is er een wijziging over het hoofd gezien, en ik zie net pas dat die er wel degelijk in en-US is geweest (zie bug 1193200) waarin de waarde van 36 naar 45 gaat. Dit zie je niet op het dashboard aangezien er al een waarde is, wel lokaal bij vergelijken van alle tekstbestanden in de source, of als er een andere wijziging is in het bestand, zoals hier.

In het verleden hebben we vaker last gehad van te kleine of (achteraf bij vergroten en verkeerd beoordeelde) te grote vensters in TB. We doen er dus verstandig aan altijd minimaal de en-US-waarden aan te houden en niet af te gaan op wat we zien. Met name bij TB zijn sommige vensters al dan niet als tijdelijke bug nogal eens niet te vergroten (door de gebruiker) als ze bij eerste gebruik toch wat te klein zijn of worden gevonden (met afgebroken knoppen als ergste gevolg), of als dat wel zo is, wordt de aangepaste venstergrootte soms niet onthouden. Ook is de tekst nu misschien wel allemaal leesbaar, maar er zijn meer regels dan in en-US die onnodig vroeg teruglopen, wat waarschijnlijk ook voor en-US de reden was om naar 45 te gaan, of alleen al omdat een tekst daarin groter is geworden of er een optie is toegevoegd (er is heus over nagedacht ;) ). Al met al zou ik dus toch 45 willen aanhouden; dit niet doen zou waarschijnlijk de enige uitzondering zijn die achteraf voor problemen kan zorgen.

Als we het echt goed zouden willen doen, moeten we zelfs met een nieuw profiel testen hoe de eerste groottes eruitzien (omdat ze nu wel aanpasbaar zijn en worden onthouden), deze vergelijken met en-US en misschien zelfs een tikkeltje hoger gaan als daarmee bijvoorbeeld net een regel wordt bespaard. Overigens bestaat er voor dit doel een scriptje dat de benodigde waarde kan opmeten/aangeven na aanpassen van een venster, maar dat werkt alleen in FF en is eigenlijk meer voor kritieke gevallen waarbij knoppen net wel of niet worden afgebroken.
Met een nieuw profiel geprobeerd, maar het past nog steeds en neemt evenveel regels in beslag als in het Engels (vier). Toch aangepast voor de zekerheid… https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/155aaea2fb89
Is eigenlijk wel fout in het Engels, als ze de waarde van een pref veranderen, moeten ze ook de naam veranderen, anders zien de localizers het niet.
diff --git a/mail/chrome/messenger/am-server-advanced.dtd b/mail/chrome/messenger/am-server-advanced.dtd

-<!ENTITY pop3Desc.label "Bij het downloaden van e-mail van deze POP3-server, de volgende map voor nieuwe e-mail gebruiken:">
-<!ENTITY accountDirectory.label "Postvak IN van deze serveraccount">
-<!ENTITY accountDirectory.accesskey "P">
+<!ENTITY pop3DeferringDesc.label "Bij het downloaden van e-mail van deze POP3-server, de volgende map voor nieuwe e-mail gebruiken:">
+<!ENTITY accountInbox.label "Postvak IN van deze account">
+<!ENTITY accountInbox.accesskey "P">

Oud: When downloading pop mail for this server, use the following folder for new mail:
Nieuw: When downloading mail from this account's server, use the following folder to store new messages: 
Oud: Inbox for this server's account 
Nieuw: Inbox for this account

Lijkt dus een algemene melding te zijn en niet specifiek voor POP. Ik zou er van maken:
"Bij het downloaden van e-mail van de server van deze account, de volgende map voor het opslaan van nieuwe berichten gebruiken:"
"Postvak IN voor deze account" (was eerst ‘van’, maar ‘voor’ toch beter - ‘serveraccount’ was trouwens ook fout)
Goed voorbeeld van heel goed kijken naar wat er wordt bedoeld, en wellicht ook de bug ervan. ;)

diff --git a/mail/chrome/messenger/am-server-top.dtd b/mail/chrome/messenger/am-server-top.dtd

+<!ENTITY useIdleNotifications.label "Directe servernotificaties toestaan als er nieuwe berichten binnenkomen">
+<!ENTITY useIdleNotifications.accesskey "D">
Ik zou ‘er’ weglaten, conform NewMessagesArrive.label.

 <!ENTITY authMethod.label "Authenticatiemethode:">
-<!ENTITY authMethod.accesskey "d">
+<!ENTITY authMethod.accesskey "A">
Ik neem aan dat je dit doet omdat een nieuwe D nodig is? Kun je s.v.p. goed controleren of deze niet elders wordt gebruikt i.c.m. een van de andere schermen of de opties onderaan aan de linkerkant? Het heeft nogal wat moeite gekost om ze te vinden. Als ik zo kijk, lijkt de a te conflicteren met ‘Andere account’ in de menu-items onder de knop linksonder, hoewel de c daarop dat nu ook al doet. Ik denk dat die items onder de knop links onderaan minder belangrijk zijn (m.a.w. onvermijdelijk) gezien de vele schermen, wat dat betreft is de a minder belangrijk dan de c daarop, omdat de keys bij openen van het scherm al bedienbaar moeten zijn, bij voorkeur di aan de rechterkant. Al met al zou ik deze key ongewijzigd laten en aangezien deze alleen voor IMAP geldt, de r gebruiken voor useIdleNotifications.accesskey; de ook gedeelde k en de m met POP-serverinstellingen zijn al in gebruik.

 <!ENTITY alwaysAuthenticate.label "Altijd om authenticatie vragen bij verbinden met deze server">
-<!ENTITY alwaysAuthenticate.accesskey "a">
+<!ENTITY alwaysAuthenticate.accesskey "A">

Deze a is hier klein gehouden (voor authenticatie) omdat de rest ook geen keys vooraan én ze vaak voor de (werk)woorden gebruikt… Zou dit liever zo houden.


diff --git a/mail/chrome/messenger/messenger.properties b/mail/chrome/messenger/messenger.properties

+remoteAllowAll=Externe inhoud van de boven vermelde #1 bron toestaan;Externe inhoud van alle boven vermelde #1 bronnen toestaan

‘bovenvermelde’ is één woord

diff --git a/mail/chrome/messenger/messengercompose/composeMsgs.properties b/mail/chrome/messenger/messengercompose/composeMsgs.properties

+msgIdentityPlaceholder=Voer aangepast Van-adres in dat gebruikt wordt in plaats van %S

Nogmaals: vormen van zijn/worden/hebben in deelwoordconstructies vóóraan, dus ‘dat wordt gebruikt’. Dit is tot nu toe consistent en moeten we zo houden.

+customizeFromAddressWarning=Als uw e-mailprovider het toestaat, kunt u met Van-adres aanpassen een eenmalige kleine wijziging aan uw Van-adres maken zonder dat u een nieuwe identiteit in Accountinstellingen hoeft aan te maken. Als uw Van-adres bijvoorbeeld John Doe <john@example.com> is, wilt u dit misschien veranderen in John Doe <john+doe@example.com> of John <john@example.com>.
Eng: If your e-mail provider supports it, Customize From Address allows you to make a one-off minor alteration to your From address without having to create a new identity in Account Settings. For example, if your From address is John Doe <john@example.com> you may want to change it to John Doe <john+doe@example.com> or John <john@example.com>. 

Ik zou volgens de oorspronkelijke tekst ‘ondersteunt’ gebruiken, evenals ‘aanbrengen in’ i.p.v. ‘maken’ (wijziging in uw Van-adres aanbrengen) (*). Dacht nog even aan Jan Smit voor het voorbeeldadres, maar gezien het gebruik van John Doe en meer nog example.com zou ik dit wel zo laten. ‘Veranderen’ is een ‘verboden woord’ (omdat dat uit zichzelf kan, niet zozeer door een gebruiker), hiervoor liever ‘wijzigen’ gebruiken. Wijzigen _naar_ overigens, niet in, dit is ook onjuist in setPriority.label in Filtereditor.dtd dus zou je ook kunnen aanpassen.
* http://taaladvies.net/taal/advies/vraag/10/aanbrengen_aan_in_wijzigingen/

diff --git a/mail/chrome/messenger/messengercompose/mailComposeEditorOverlay.dtd b/mail/chrome/messenger/messengercompose/mailComposeEditorOverlay.dtd
 <!ENTITY attachImageSource.label         "Deze afbeelding aan het bericht koppelen">
-<!ENTITY attachImageSource.accesskey     "b">
+<!ENTITY attachImageSource.accesskey     "D">
 <!ENTITY attachLinkSource.label          "De bron van deze koppeling aan het bericht koppelen">
-<!ENTITY attachLinkSource.accesskey      "b">
+<!ENTITY attachLinkSource.accesskey      "D">

Waarom? Zie geen reden om dit te doen, net als hierboven is het somes handiger om het accent op een bepaald woord te leggen, net als in de Engelse tekst.

diff --git a/mail/chrome/messenger/preferences/compose.dtd b/mail/chrome/messenger/preferences/compose.dtd

+<!ENTITY enterKeyCreatesNewParagraph.label    "Als u tekstopmaak Alinea gebruikt, creëert de Enter-toets een nieuwe alinea">
+<!ENTITY enterKeyCreatesNewParagraph.accesskey "E">
Eng: When using paragraph format, the enter key creates a new paragraph

De E wordt al gebruikt, de A lijkt vrij te zijn. Als je hier begint met ‘Bij gebruik van tekstopmaak Alinea,’, komt die mooi uit.
Er is overigens een tijd geweest waarin we ‘creëren’ grondig hebben vervangen door ‘(aan)maken’. Wellicht heb je in de editor-strings gekeken en ook elders gezien dat ‘creëren"’ of ‘creëert’ nog/wel voorkomt, dus hier wel OK. Als (in het algemeen) ‘maken’ wel kan of gangbaarder is, kan dat worden gebruikt.

diff --git a/mail/chrome/messenger/preferences/sendoptions.dtd b/mail/chrome/messenger/preferences/sendoptions.dtd

+<!ENTITY autoDowngrade.label          "Verzend berichten indien mogelijk als platte tekst">
+<!ENTITY autoDowngrade.accesskey      "b">
Eng: Send messages as plain text if possible

Uiteraard infinitief gebruiken, gebiedende wijs uitsluited als het een tekst/opdracht richting gebruiker is. Vermijd ook altijd het gebruik van ‘indien’ (is al eens eerder overal vervangen meen ik) en gebruik hiervoor ‘wanneer’ of ‘als’. -> Berichten wanneer mogelijk als platte tekst verzenden

( Zie ook <!ENTITY sendBoth.label               "Bericht als platte tekst en HTML verzenden"> )

diff --git a/mail/chrome/overrides/netError.dtd b/mail/chrome/overrides/netError.dtd
 
+<!ENTITY forbiddenBlocked.title "Verboden website">
+<!ENTITY forbiddenBlocked.longDesc "<p>&brandShortName; heeft voorkomen dat deze pagina werd geladen, omdat het geconfigureerd is om hem te blokkeren.</p>
+">

Als je naar de soortgelijke strings in de andere neterror-bestanden kijkt, zie je dat ik daarin de ‘hem’ die hier staat bewust ‘de pagina’ heb genoemd. Het is wel zo fijn/consistent om dat hier ook aan te houden. Ook: ‘is geconfigureerd’ i.p.v. ‘geconfigureerd is’ om de bovengenoemde reden. ‘Het’ voor Thunderbird is denk ik wel OK, al zou je ook ‘het programma’ kunnen gebruiken, à la ‘de browser’.

Tot zover de recente wijzigingen. Verder zag ik nog dit:
- Out of memory: liever ook ‘Onvoldoende geheugen’ gebruiken voor consistentie (ldap.p)
- Ongewensteberichtenmap leegmaken: gebruikt de key t, die conflicteert met de t voor het meen ik later geïntroduceerde Openen in nieuw tabblad (in contextmenu), wellicht is de w te gebruiken i.p.v. de l - de O is al in gebruik. Ook vraag ik me af of dit niet beter ‘Map Ongewenst leegmaken’ kan zijn - het is mogelijk dat ‘ongewensteberichtenmap’ nog stamt uit de tijd dat de map Ongewenst nog Ongewenste berichten heette (we hadden deze dus ook Map Ongewenste berichten leegmaken kunnen noemen, maar dat werd iets langer), maar buiten dat is de term nu ook wat lang, net als ongewensteberichtenverwerking.
- Accountinstellingen - Kopieën en mappen - Anders en Archiveringsopties hebben beide de A. Ook de C wordt in twee gevallen gebruikt en werkt niet, en conflicteert zelfs met de C in de knop links onderaan. De A voor Archiveringsopties is later gekomen en zou de h kunnen worden. voor beide c's is nog een stoelendans nodig om dat te vermijden en wellicht een zeldzame key voor Accountacties te vinden waardoor alle schermen er ook van profiteren, wellicht later.

Tot slot: Instantbird gebruikt de strings in comm-central voor de map Chat, die op dit moment identiek is aan die van comm-aurora. IB heb ik laatst bijgewerkt en daardoor nog wat onjuistheden voor NL aangetroffen. Als je zin hebt, zou je die eens kunnen vergelijken en tergvoeren naar TB, of als je het makkelijker vindt, kan ik daaruit een patch maken voor TB of deze direct kunnen toepassen. Mocht ik daarin wat onjuist hebben gedaan, kan/moet/zal dat uiteraard ook weer in IB worden doorgevoerd.
Ik zag net nog 3 kleinigheidjes in bestaande strings:
> insecureUnencrypted.description "Uw e-mail en authenticatie worden niet-versleuteld verzonden, dus uw wachtwoord (en uw bericht) kunnen gemakkelijk worden gelezen door anderen. &brandShortName; geeft u toegang tot uw e-mail, maar u zou uw e-mailprovider kunnen vragen de server te configureren met een beveiligde verbinding.

Ik zou daarvan maken:
Uw e-mail en authenticatie worden onversleuteld verzonden, dus uw wachtwoord (en uw bericht) kunnen gemakkelijk door anderen worden gelezen. &brandShortName; geeft u toegang tot uw e-mail, maar u zou uw e-mailprovider kunnen vragen de server met een beveiligde verbinding te configureren.
(onversleuteld, 2 x woordvolgorde)

> invalidCustomHeader=Eén van uw filters gebruikt...
-> Een van uw filters gebruikt...
> corruptMabFileAlert=Eén van uw adresboekbestanden...
-> Een van uw adresboekbestanden...
(geen klemtoon nodig)
Nog een paar verbeteringen in accesskeys bij Accountinstellingen pane Serverinstellingen (de r bij Op nieuwe berichten controleren bij opstarten conflicteerde bij een POP3-server) en pane Kopieën & mappen (de l bij Antwoorden plaatsen in de map van het bericht waarop wordt geantwoord is in sommige windows 1 pixel breed, dus hernoemd naar w en daarvoor moest de w vrijgemaakt worden bij Bevestiging weergeven als berichten zijn opgeslagen, dus dat is de z geworden.
En de accesskeys bij de verschillende Anders heb ik gesorteerd, van boven naar beneden van links naar rechts.
https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/77ca97e11c0a
Certificatieautoriteit -> certificaatautoriteit: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/885eb46cfc40
Komma's, is->lijkt, Bewaren->Verplaatsen button, Quotuminformatie->quotumgegevens: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/951d577a2595
Verbetering confirmDeleteCollectoinAddressbook: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/72fce8ad979b
TB Aurora 47.0a2 is klaar voor controle: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/49a5aaba63a6
Maar 5 strings dit keer, waarvan eentje mijn patch in bug 1249865 :-)
Foutjes in TB gevonden tijdens controle SeaMonkey: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/d0834f4916fb
Thunderbird 49.0a2 Aurora is klaar voor controle: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/d75de8728451
Thunderbird nog een keer op consistentie gecontroleerd a.d.h.v transvision: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/2438852b81b9
Verbeteringen mail n.a.v. opmerkingen Tonnes: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/2019e35ce6096779e5873208d389f9524483de70
(commit bevat per ongeluk ook verbeteringen voor chat en seamonkey)
Depends on: tb-nl
Vanaf nu werken we weer in central, zie bug 1357707 (alias tb-nl), dus ik sluit deze bug.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.