Closed Bug 457393 Opened 16 years ago Closed 8 years ago

[nl] mozilla-aurora/nl seamonkey

Categories

(Mozilla Localizations :: nl / Dutch, defect)

Product:
Mozilla Localizations
Component:
nl / Dutch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mad_maks, Assigned: nONoNonO)

References

Details

Attachments

(27 obsolete files)

Dit is de nieuwe bug voor het werk aan Seamonkey 2 in mercurial
Depends on: 468311
We gaan verder in bug 468311 voor de vertaling van Seamonkey 2. Voor het taalpakket van Seamonkey 2 alpha 2 zie http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2.0a2-candidates/build1/langpack/
No longer depends on: 468311
Assignee: dutch.nl → niek
Status: NEW → ASSIGNED
nl/suite/chrome/common/notification.properties: added new geolocation keys/removed obsolete keys nl/suite/chrome/common/permissions/cookieViewer.properties: added new keys for removal of selected cookie sites wording change (kan -> mag)
Comment on attachment 369592 [details] [diff] [review] Geolocation and Cookiesites localization update toegepast op central en 1.9.1.. gefeliciteerd met je eerste patch!
Attachment #369592 - Attachment is obsolete: true
Updates the following files: nl/suite/chrome/mailnews/addressbook/addressBook.properties nl/suite/chrome/mailnews/folderProps.dtd nl/suite/chrome/mailnews/messenger.properties nl/suite/chrome/mailnews/pref/am-addressing.dtd nl/suite/chrome/mailnews/pref/am-main.dtd nl/suite/chrome/mailnews/pref/pref-mailnews.dtd nl/suite/chrome/mailnews/pref/prefs.properties nl/suite/chrome/mailnews/search-attributes.properties
Attachment #374112 - Attachment is obsolete: true
Comment on attachment 374112 [details] [diff] [review] nl localization updates as of April 22, 2009 toegepast
Current update of the Dutch localization of Seamonkey. The following files are - changed: M suite\chrome\browser\pageInfo.properties M suite\chrome\common\notification.properties M suite\chrome\common\pref\pref-applications.properties M suite\chrome\mailnews\addressbook\abCardOverlay.dtd M suite\chrome\mailnews\messenger.dtd M suite\chrome\mailnews\messenger.properties M suite\chrome\mailnews\pref\AccountManager.dtd - added: A suite\chrome\common\feeds\subscribe.dtd A suite\chrome\common\feeds\subscribe.properties A suite\chrome\common\search\search-rdf.dtd A suite\chrome\mailnews\pref\am-addressing.dtd.orig A suite\profile\bookmarks.extra A suite\profile\bookmarks.inc A suite\profile\panels.extra A toolkit\chrome\global\history\history.properties - removed: R suite\profile\bookmarks.html R suite\profile\localstore.rdf R suite\profile\mimeTypes.rdf R suite\profile\panels.rdf R suite\profile\search.rdf
Comment on attachment 379383 [details] [diff] [review] nl localization updates as of May 23, 2009 patch toegepast op 1.9.1 en central. Een paar opmerkingen. Toolkit bestanden NIET in deze bug aanbieden. Op een aantal plekken is een string anders vertaald dan in firefox en/of thunderbird. In principe moet een string die ook in fX en tb voorkomt overgenomen worden. Tenzij je natuurlijk van mening bent dat deze niet juist is maar dan moet je de reden aangeven in deze bug. De patch is toegepast maar graag nog wel een keer nalopen op verschillen met tb en fx
Attachment #379383 - Attachment is obsolete: true
(In reply to comment #7) > (From update of attachment 379383 [details] [diff] [review]) > > Op een aantal plekken is een string anders vertaald dan in firefox en/of > thunderbird. In principe moet een string die ook in fX en tb voorkomt > overgenomen worden. Tenzij je natuurlijk van mening bent dat deze niet juist is > maar dan moet je de reden aangeven in deze bug. > > De patch is toegepast maar graag nog wel een keer nalopen op verschillen met tb > en fx Volledig mee eens. Probeer s.v.p., zoals we ooit eens hebben besproken via irc, eerst de source te ontdoen van de vele spel- en vertaalfouten die er op dit moment nog in staan. Gebruik daarvoor als het kan een diff-tool en de taalbestanden uit het meest recente 1.1-pakket; dit is zowel qua opbouw als verwijderde fouten en optimalisaties in FF en TB tot enkele maanden geleden bijgewerkt. Behandel daarna de verschillen t.o.v. de SM 2.0-tree; zorg daarbij goed voor consistentie met de rest en introduceer als het kan geen nieuwe fouten als je er toch mee bezig bent. ;) Pas als laatste zou je woorden of hele zinnen anders kunnen vertalen als daar een goede reden voor is, maar koppel dit terug of plaats voorstellen hiertoe in de bug, zodat dit ook in FF/TB terugkomt en tevens gelijk blijft, tenzij het op praktische redenen onmogelijk is (zoals bepaalde access keys in afwijkende menu’s). Op deze manier houden we 1) een foutloze vertaling en b) het overzicht intact. Weet i.i.g dat ik ditzelfde eerdaags ga doen als de tijd er is, dus de kans bestaat dat wijzigingen in de patch hierboven teniet worden gedaan. Maar wellicht kun je hier beter eerst zelf naar kijken, zoals Tim al schreef. Verder goed werk.
Aanleiding: Zie l10n-dashboard Comparison for suite-nl http://l10n.mozilla.org/buildbot/compare/hg-comm-langpack/22383 Strings v. downloadmanager toegevoegd markAsReadNoDelay stringvergelijking: SM en_US: <!ENTITY markAsReadNoDelay.label "Immediately on display"> TB nl_NL: <!ENTITY markAsReadNoDelay.label "Direct zichtbaar"> SM nl_nl: <!ENTITY markAsReadNoDelay.label "Onmiddelijk op het scherm"> (bevat spelfout) voorstel zie tekst enkele evidente taal-, spelling- en selectietoets-issues verbeterd onderweg undeleteButton.label: string overgenomen van Thunderbird-nl Commentaar welkom
Attachment #382038 - Attachment is obsolete: true
Comment on attachment 382038 [details] [diff] [review] nl localization updates as of June 7, 2009 toegepast op 1.9.1 en central
De drie nieuwe files behorend bij de nieuwe downloadbeheerder zijn niet in de repository terechtgekomen. Ik weet niet wat de oorzaak is. Tim, kun je dat verifiëren?
(In reply to comment #11) > De drie nieuwe files behorend bij de nieuwe downloadbeheerder zijn niet in de > repository terechtgekomen. Ik weet niet wat de oorzaak is. Tim, kun je dat > verifiëren? ik denk dat ik de addremove commando vergeten ben, zal het doen als ik weer thuis ben.
(In reply to comment #12) > (In reply to comment #11) > > De drie nieuwe files behorend bij de nieuwe downloadbeheerder zijn niet in de > > repository terechtgekomen. Ik weet niet wat de oorzaak is. Tim, kun je dat > > verifiëren? > > ik denk dat ik de addremove commando vergeten ben, zal het doen als ik weer > thuis ben. gedaan
l10n-mozilla-1.9.1 freeze date: 2009-07-16 voor seamonkey 2.0 beta 1
Attached patch updates per 1 juli 2009 (obsolete) — — Splinter Review
Updates per 1 juli 2009 Aanleiding: zie l10n-dashboard Comparison for suite-nl http://l10n.mozilla.org/buildbot/compare/hg-comm-langpack/23997 Zie ook de opmerkingen op http://www.mozbrowser.nl/forum/viewtopic.php?f=18&t=17312&sid=afd48235c4cd188d97e90736b1b572e8#p107518 Commentaar is welkom. Besch. tijd is op dit moment beperkt.
Comment on attachment 386340 [details] [diff] [review] updates per 1 juli 2009 toegepast op 1.9.1 en central
Attachment #386340 - Attachment is obsolete: true
(In reply to comment #16) > Besch. tijd is op dit moment beperkt. ik heb veranderingen aan Thunderbird ook doorgevoerd in Seamonkey http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/nl/rev/e62e1f13b688
quote: "to target a freeze for Beta 2 on September 1 and assure that we will release final before November. We will re-evaluate the target freeze date in the next meeting on August 11 and make firm schedules there" dus we moeten niet te lang wachten met het bijwerken van de bestanden, ik zal de veranderingen in Thunderbird (bug 468310) ook in Seamonkey doorvoeren maar de rest verwacht ik via deze bug. voor de helpbestanden heb ik bug 508742 aangemaakt
Depends on: 508742
de veranderingen in TB zijn doorgevoerd in Seamonkey
Attached patch updates per 14 augustus 2009 (obsolete) — — Splinter Review
Kennis nemende van de patches voor TB die in SM zijn doorgevoerd. Deze patch adresseert de ontbrekende en overbodig geworden vertalingen op http://l10n.mozilla.org/buildbot/compare/hg-comm-langpack/26257. Betreft in pref-download.dtd deels opmaak/witregels gelijk maken aan de engelse versie. Gelieve dit als voorstel te beschouwen. Commentaar is welkom.
(In reply to comment #22) > Kennis nemende van de patches voor TB die in SM zijn doorgevoerd. > Veranderingen in Tb/SM waar fouten in zitten of waar je het niet mee eens bent graag melden in bug 468310
Comment on attachment 394525 [details] [diff] [review] updates per 14 augustus 2009 toegepast
Attachment #394525 - Attachment is obsolete: true
Is het een idee om te opteren voor een localized build in de release van Seamonkey 2.0 beta 2, RC1, of Final, indien die gelegenheid wordt geboden? Vergelijk de opt-in thread voor beta 1 (zie http://groups.google.com/group/mozilla.dev.l10n/browse_thread/thread/229e402bdeca8d44). Welke stappen zijn daarvoor benodigd?
(In reply to comment #25) > Is het een idee om te opteren voor een localized build in de release van > Seamonkey 2.0 beta 2, RC1, of Final, indien die gelegenheid wordt geboden? > Vergelijk de opt-in thread voor beta 1 (zie > http://groups.google.com/group/mozilla.dev.l10n/browse_thread/thread/229e402bdeca8d44). > Welke stappen zijn daarvoor benodigd? Dat is wel de intentie, ik had het ook willen doen voor beta 1 maar toen was ik op vakantie. - zorg ervoor dat de dashboard groen is - test de build die na de laatste commit gemaakt wordt - beantwoord de opt-in thread met de link naar de laatste commit (op dit moment http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/nl/rev/5bcb65f6e5e6 )
Akkoord. Voor beta2 (deadline 1 sept, dinsdag dus) is dat kort dag wegens familiale verplichtingen. Ik zal zien of ik morgen met een patch kan komen. Als alles meezit kunnen we dan nog mee.
(In reply to comment #27) > Akkoord. Voor beta2 (deadline 1 sept, dinsdag dus) is dat kort dag wegens > familiale verplichtingen. Ik zal zien of ik morgen met een patch kan komen. Als > alles meezit kunnen we dan nog mee. 1 september is nog geen harde deadline. het beste is om dan idd de patch toegepast te hebben maar met ene beetje mazzel kan het een dag later ook nog.
Deze patch adresseert de ontbrekende en gewijzigde vertalingen op http://l10n.mozilla.org/buildbot/compare/hg-comm-langpack/27226 en enkele kleine harmonisaties. Bij instemming zou deze patch kunnen leiden tot opt-in van nl voor de beta-2 release. Gelieve dit als voorstel te beschouwen. Commentaar is, zoals altijd, zeer welkom.
Comment on attachment 397633 [details] [diff] [review] updates per 31 augustus 2009 (beta2 opt-in) toegepast op 1.9.1 en central
Attachment #397633 - Attachment is obsolete: true
Bij het testen van de laatste nightly zag ik de volgende punten: - voorkeuren venster linux is te smal, ik kom op de volgende waarde uit om het goed te krijgen: <!ENTITY prefWindow.size "width:59em; height: 41em;"> - Een aantal acceskeys in de voorkeuren zijn nog niet goed. - nl/suite/chrome/common/pref/pref-cache.dtd bevat niet vertaalde regels
uit de l10n nieuwsgroep en van toepassing op nl: Dear SeaMonkey localizers, It appears that I landed a string change in suite/chrome/browser/tabbrowser.properties this tuesday without doing the needed changes to the id/entity name: --- a/suite/locales/en-US/chrome/browser/tabbrowser.properties Tue Aug 25 11:06:18 2009 -0700 +++ b/suite/locales/en-US/chrome/browser/tabbrowser.properties Tue Aug 25 22:29:57 2009 +0200 @@ -1,5 +1,5 @@ tabs.loading=Loading? -tabs.untitled=(Untitled) +tabs.untitled=Untitled tabs.closeWarningTitle=Confirm Closing Other Tabs tabs.closeWarning=You are about to close %S other tab(s). Are you sure you want to continue? tabs.closeButton=Close other tabs Sorry about that. I think a few of you have noticed it, but most of you probably haven't. Regards, /Stefan
(In reply to comment #31) > - nl/suite/chrome/common/pref/pref-cache.dtd bevat niet vertaalde regels Naar aanleiding van bovenstaande bevinding bereid ik de vertaling voor van de volgende termen: "Link Prefetching" "Prefetch web pages when idle, so that links in web pages designed for prefetching can load more quickly"> Over de vertaling van de term 'Link Prefetching' is overleg gewenst. Bestaat over de vertaling hiervan al consensus. En indien niet, wat zijn dan de overwegingen van de medevertalers met betrekking tot de vertaling hiervan.
(In reply to comment #33) > Naar aanleiding van bovenstaande bevinding bereid ik de vertaling voor van de > volgende termen: > > "Link Prefetching" > "Prefetch web pages when idle, so that links in web pages designed for > prefetching can load more quickly"> Deze tekst (in hetzelfde bestand) is in het 1.1-pakket toch al vertaald? Is dit misschien niet opgevallen, of zie je reden om hiervan af te wijken?
Tonnes, Ik was me daar niet van bewust. Hoe is het daar vertaald?
Ik heb het even opgezocht: <!ENTITY prefetchTitle.label "Koppelingen vooraf ophalen"> <!ENTITY enablePrefetch.label "Webpagina’s vooraf ophalen wanneer ongebruikt, zodat koppelingen in webpagina’s die hiervoor zijn ontworpen sneller kunnen laden"> <!ENTITY enablePrefetch.accesskey "v">
ik heb vandaag nog wat testen gedaan: de nl versie werkt naar behoren. het meest opvallende is dat http://mxr.mozilla.org/l10n-central/source/nl/suite/profile/bookmarks.inc nog niet vertaald is.
* Feature Freeze: already in place since September 1st * String freeze: Thursday, October 1st 23:59 PDT / 2009-10-02 06:59 UTC ** This is final string freeze for the SeaMonkey 2.0 series! * Code freeze: Tuesday, October 6th 23:59 PDT / 2009-10-07 06:59 UTC ** All patches need approval after that, even on blocker and wanted bugs * RC1 build start: Wednesday, October 7th * RC1 Release ASAP after basic functional test of builds * Final Release: later in October, probably NET October 20
Attached patch Voorkeurenvensters patch deel 1 (obsolete) — — Splinter Review
De voorkeurenvensters bevatten onvertaalde tekstelementen, tekstelementen met kleine foutjes en tekstelementen die voor verbetering vatbaar zijn. Deze patch adresseert een aantal van de vensters. In een volgende patch, in te dienen voor de freeze van SeaMonkey 2.0 final, zullen de resterende geadresseerd worden. De bestaande strings in SeaMonkey 1.1.x nl vormen hierbij het uitgangspunt. Met dank aan Tonnes voor het attenderen hierop. Ook de breedte van het voorkeurenvenster in Linux wordt in deze patch geadresseerd.
Attachment #402314 - Attachment is obsolete: true
Comment on attachment 402314 [details] [diff] [review] Voorkeurenvensters patch deel 1 toegepast op 1.9.1 en central met een aanpassing: -<!ENTITY socks.description "Een SOCKS proxy is een algemen proxy die soms gebruikt wordt in een kantooromgeving"> +<!ENTITY socks.description "Een SOCKS-proxy is een algemene proxy die soms wordt gebruikt in een kantooromgeving"> -<!ENTITY socks.label "SOCKS Proxy:"> +<!ENTITY socks.label "SOCKS-Proxy:">
(In reply to comment #41) > -<!ENTITY socks.label "SOCKS Proxy:"> > +<!ENTITY socks.label "SOCKS-Proxy:"> Maar dan met een kleine… p ;)
Ik zie overigens nog meer dingen, zoals +<!ENTITY protocols.caption "Protocol-specifieke proxies"> +<!ENTITY externalDescription.label "Koppelingen die vanuit andere applicaties geopend worden tonen in"> +<!ENTITY protocols.description "Een proxy-server voor elk protocol instellen"> +<!ENTITY reuseProxy.label "HTTP proxy-server gebruiken voor alle protocollen"> <!ENTITY proxyTitle.label "Proxies instellen voor toegang tot het Internet"> <!ENTITY SSLWarnings.caption "SSL waarschuwingen"> Niek, zou je e.e.a. nog eens naast de bestanden van 1.1 willen houden? Let ook op de ‘rode’ stijl (worden …), gekrulde apostroffen/aanhalingstekens etc. Of volgen die zaken nog? (Het schiet me nu te binnen dat je je eerstens alleen wilde bezighouden met onvertaalde zaken, dus dan zijn deze zaken verklaarbaar, ook n.a.v. comment 40).
We expect the generation of RC1 builds right after the code freeze on Tuesday, October 6 at 23:59 PDT, so opt in before that if you want to be able to hand that candidate to your and our community for testing in your locale. If a few things are not 100% perfect there, it's OK, we know that we'll very probably do a RC2 after that, for which we expect everything, including locales, to be in shipping order then, though.
Zie http://l10n.mozilla.org/buildbot/compare/hg-comm-langpack/33578 en zie opmerking over socks-proxy. De aaneenschrijving in 'is gratis en opensourcesoftware' is niet juist. 'opensource' is evenals 'gratis' een bepaling bij 'software', zoals blijkt uit 'en'. Wel juist gespeld zou zijn: 'is gratis opensourcesoftware', omdat nu 'opensourcesoftware' het zelfstandig naamwoord in de zin is geworden. Committer: de patch bevat nieuwe files.
Comment on attachment 404596 [details] [diff] [review] Updates suite per 5 oktober 2009 (rc1) toegepast op central en 1.9.1 opmerkingen: -<!ENTITY openHelpCmd.label "Help inhoud"> >+<!ENTITY openHelpCmd.label "Helpinhoud"> heb ik ook veranderd in /nl/suite/chrome/common/win/platformCommunicatorOverlay.dtd. met de verandering : -<!ENTITY phishingBarMessage.label "&brandShortName; denkt dat dit bericht misschien een e-mailscam is."> -<!ENTITY removePhishingBarButton.label "Geen scam"> +<!ENTITY phishingBarMessage.label "&brandShortName; denkt dat dit bericht misschien een phishing e-mail is."> +<!ENTITY removePhishingBarButton.label "Geen phishing e-mail"> wijk je nu af van de thunderbirdvertaling, ik denk dat je dat moet terugdraaien (zie http://mxr.mozilla.org/l10n-central/search?string=phishingBarMessage&find=%2Fnl%2F&findi=&filter=^[^\0]*%24&hitlimit=&tree=l10n-central)
Attachment #404596 - Attachment is obsolete: true
(In reply to comment #45) > De aaneenschrijving in 'is gratis en > opensourcesoftware' is niet juist. 'opensource' is evenals 'gratis' een > bepaling bij 'software', zoals blijkt uit 'en'. Wel juist gespeld zou zijn: 'is > gratis opensourcesoftware', omdat nu 'opensourcesoftware' het zelfstandig > naamwoord in de zin is geworden. Daar ben ik het niet mee eens. In het Engels schrijft men in deze zin vanzelfsprekend alles los. In het Nederlands echter is opensourcesoftware te allen tijde één woord, evenals in bv. opensourcelicentie. M.a.w. ‘opensource’ is hier geen bepaling bij software (het is geen geldig bijvoeglijk naamwoord en staat als zodanig ook niet in Van Dale); zie hiervoor diverse netdiscussies, http://nl.wikipedia.org/wiki/Opensourcesoftware e.v. Wat ‘gratis’ betreft: dat mag dan een bepaling zijn, maar in een dergelijk geval wordt het tweede deel als ik me niet vergis gewoon aaneen geschreven, zelfs als dat zou betekenen dat er, zoals hier, verwarring in betekenis kan ontstaan. Ik kan niet zo gauw een ander voorbeeld hiervan (of de bijbehorende regel) vinden, maar als het moet wil ik er wel naar zoeken. (In reply to comment #46) > > met de verandering : > -<!ENTITY phishingBarMessage.label "&brandShortName; denkt dat dit bericht > misschien een e-mailscam is."> > -<!ENTITY removePhishingBarButton.label "Geen scam"> > +<!ENTITY phishingBarMessage.label "&brandShortName; denkt dat dit bericht > misschien een phishing e-mail is."> > +<!ENTITY removePhishingBarButton.label "Geen phishing e-mail"> > > wijk je nu af van de thunderbirdvertaling, ik denk dat je dat moet terugdraaien Lijkt me ook beter; buiten dat bevat ‘phishing e-mail’ een spatie, en dat willen we natuurlijk niet. ;-)
(In reply to comment #46) > (From update of attachment 404596 [details] [diff] [review]) > toegepast op central en 1.9.1 > > opmerkingen: > -<!ENTITY openHelpCmd.label "Help inhoud"> > >+<!ENTITY openHelpCmd.label "Helpinhoud"> > > heb ik ook veranderd in > /nl/suite/chrome/common/win/platformCommunicatorOverlay.dtd. > > met de verandering : > -<!ENTITY phishingBarMessage.label "&brandShortName; denkt dat dit bericht > misschien een e-mailscam is."> > -<!ENTITY removePhishingBarButton.label "Geen scam"> > +<!ENTITY phishingBarMessage.label "&brandShortName; denkt dat dit bericht > misschien een phishing e-mail is."> > +<!ENTITY removePhishingBarButton.label "Geen phishing e-mail"> > > wijk je nu af van de thunderbirdvertaling, ik denk dat je dat moet terugdraaien > (zie > http://mxr.mozilla.org/l10n-central/search?string=phishingBarMessage&find=%2Fnl%2F&findi=&filter=^[^\0]*%24&hitlimit=&tree=l10n-central) Ik kan geen aanwijzingen vinden dat het begrip scam in het Nederlandse taalgebied gebruikelijker is dan het begrip phishing. Integendeel, het lijkt me dat het laatste meer in de taal opgenomen is. Banken en nieuwssites gebruiken het woord phishing geregeld om consumenten te waarschuwen. Ik stel voor om de vertaling in Thunderbird aan te passen.
(In reply to comment #47) > (In reply to comment #45) > > > De aaneenschrijving in 'is gratis en > > opensourcesoftware' is niet juist. 'opensource' is evenals 'gratis' een > > bepaling bij 'software', zoals blijkt uit 'en'. Wel juist gespeld zou zijn: 'is > > gratis opensourcesoftware', omdat nu 'opensourcesoftware' het zelfstandig > > naamwoord in de zin is geworden. > > Daar ben ik het niet mee eens. In het Engels schrijft men in deze zin > vanzelfsprekend alles los. In het Nederlands echter is opensourcesoftware te > allen tijde één woord, evenals in bv. opensourcelicentie. M.a.w. ‘opensource’ > is hier geen bepaling bij software (het is geen geldig bijvoeglijk naamwoord en > staat als zodanig ook niet in Van Dale); zie hiervoor diverse netdiscussies, > http://nl.wikipedia.org/wiki/Opensourcesoftware e.v. > Wat ‘gratis’ betreft: dat mag dan een bepaling zijn, maar in een dergelijk > geval wordt het tweede deel als ik me niet vergis gewoon aaneen geschreven, > zelfs als dat zou betekenen dat er, zoals hier, verwarring in betekenis kan > ontstaan. Ik kan niet zo gauw een ander voorbeeld hiervan (of de bijbehorende > regel) vinden, maar als het moet wil ik er wel naar zoeken. > > (In reply to comment #46) > > > > met de verandering : > > -<!ENTITY phishingBarMessage.label "&brandShortName; denkt dat dit bericht > > misschien een e-mailscam is."> > > -<!ENTITY removePhishingBarButton.label "Geen scam"> > > +<!ENTITY phishingBarMessage.label "&brandShortName; denkt dat dit bericht > > misschien een phishing e-mail is."> > > +<!ENTITY removePhishingBarButton.label "Geen phishing e-mail"> > > > > wijk je nu af van de thunderbirdvertaling, ik denk dat je dat moet terugdraaien > > Lijkt me ook beter; buiten dat bevat ‘phishing e-mail’ een spatie, en dat > willen we natuurlijk niet. ;-) Je hebt me er niet van overtuigd dat 'Puntjepuntje is gratis en opensourcesoftware' correct Nederlands is. Je zult met betere argumenten moeten komen ;) Wat de spaties bij phishing betreft, dat willen we inderdaad niet.
(In reply to comment #48) > Ik kan geen aanwijzingen vinden dat het begrip scam in het Nederlandse > taalgebied gebruikelijker is dan het begrip phishing. Integendeel, het lijkt me > dat het laatste meer in de taal opgenomen is. Banken en nieuwssites gebruiken > het woord phishing geregeld om consumenten te waarschuwen. Ik stel voor om de > vertaling in Thunderbird aan te passen. Ik zou zeggen dat geen van beiden heel erg in de taal is opgenomen :). De vertaling als ‘scams’ is waarschijnlijk zo omdat de Engelse zin over ‘scam’ spreekt. Ondanks dat er in het label ‘phishing’ staat. Ook: phishing is een scam, maar dat geldt niet andersom, het is een subset. Kunnen we niet gewoon gaan voor een Nederlandse term? Oplichting, frauduleus, bedrog, zwendel, misleiding… er zijn zoveel woorden die wel zouden passen.
(In reply to comment #45) > Created an attachment (id=404596) [details] > Updates suite per 5 oktober 2009 (rc1) Ook: distribueren → verspreiden modificeren → aanpassen update-service → update-dienst informatie over het uitschakelen van de diensten → deze diensten service terms → gebruiksvoorwaarden discontinueren → beëindigen Deze voorwaarden vallen onder de wetten → vallen onder de wet/wetgeving met uitzondering van zijn bepalingen van → van de bepalingen met betrekking tot/betreffende Tijdens het starten van het ophalen van een bestand → Tijdens het beginnen met geavanceerd… → Geavanceerd… Downloadmanager laten oplichten → Downloadbeheerder laten oplichten De Downloadbeheerder openen → De downloadbeheerder openen Mail &amp; Nieuwsgroepen → Mail &amp; nieuwsgroepen Netwerk &amp; Schijfruimte → Netwerk &amp; schijfruimte Antivirusprogramma's → Antivirusprogramma’s (apostrof) M.b.t. “straffende of gevolgschade”, ‘straffende schade’ bestaat niet. Punitive damages (“hoge schadevergoeding (als straf)”), waar men het hier over heeft, is een boete die van extreme hoogte is om een voorbeeld te stellen. M.b.t. “Sommige wetgevingen staan uitsluitingen of beperkingen van bepaalde garanties niet toe”, in het Engels staat er “Some jurisdictions do not allow the exclusion or limitation of certain damages”, ik denk niet dat je ‘damages’ als ‘garanties’ kunt vertalen. En om nog op opensourcesoftware terug te komen, wat mij betreft moet dit inderdaad ook één woord zijn. Ook mij lijkt “is gratis en opensourcesoftware” of misschien wel “is gratis- en opensourcesoftware” (ook al schrijf je gratis software niet aan elkaar) beter Nederlands. En ten slotte: - <!ENTITY clearLocationBar.label "De lijst met in het locatiebalkmenu opgeslagen stekken wissen."> Oei, zat die er werkelijk nog steeds in!? :)
Robert Kaiser wrote: I'll take this for RC1, but please update http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/nl/file/f0e288d10f2d/suite/chrome/branding/brand.properties from .add-ons.mozilla.org to .add-ons.mozilla.com, we need this change for 2.0 final so people don't get warned about invalid certificates.
Comment on attachment 404887 [details] [diff] [review] brand.properties org > com https url toegepast op central en 1.9.1
Attachment #404887 - Attachment is obsolete: true
(In reply to comment #49) > > Je hebt me er niet van overtuigd dat 'Puntjepuntje is gratis en > opensourcesoftware' correct Nederlands is. Je zult met betere argumenten moeten > komen ;) Wat de spaties bij phishing betreft, dat willen we inderdaad niet. Ik weet niet of het aan mij is met betere argumenten te komen. ;) Maar goed, het is een goede gewoonte om in het geval van een combinatie van bijvoeglijk naamwoord + zelfstandig naamwoord, gevolgd door een samenstelling met hetzelfde bijvoeglijk naamwoord, het laatste eerst los te schrijven en daarna pas de samenstelling. Zo schrijven we bv. niet ‘gevolg- en straffende schade’, maar wel zoals hierboven. Dit is de reden voor de keuze van ‘gratis en opensourcesoftware’, met zoals gezegd, kans om mogelijke verwarring. Die verwarring vind ik persoonlijk niet eens erg; Firefox is immers gratis, dus of men hier nu per sé ‘gratis software’ moet uitdrukken is niet zo belangrijk. Het is meer toeval dat dit in het Engels wel kan, áls dit hier tenminste al de bedoeling is; wie zegt dat men niet hetzelfde bedoelt, dus ‘ … is gratis en … is opensourcesoftware’? Zou je echt de bepalingen expliciet gescheiden willen houden, dan kom je uit bij ‘gratis en open source software’ en volgt weer de discussie over het los schrijven van opensourcesoftware (en zelfs van ‘open source’ waar het bijvoeglijk wordt gebruikt) die eindigt bij het aan elkaar schrijven ervan, en dan nog blijft de vraag of gratis nu wel of niet op software slaat. Geloof me, dit geval is me ten tijde van de vertaling niet ontgaan, en het lijkt me niet verstandig of noodzakelijk dit te veranderen.
(In reply to comment #50) > (In reply to comment #48) > > Ik kan geen aanwijzingen vinden dat het begrip scam in het Nederlandse > > taalgebied gebruikelijker is dan het begrip phishing. Integendeel, het lijkt me > > dat het laatste meer in de taal opgenomen is. Banken en nieuwssites gebruiken > > het woord phishing geregeld om consumenten te waarschuwen. Ik stel voor om de > > vertaling in Thunderbird aan te passen. > > Ik zou zeggen dat geen van beiden heel erg in de taal is opgenomen :). Hmja, dat is nu eenmaal zo. Phishing staat inmiddels in Van Dale, scam helaas (nog) niet. > De vertaling als ‘scams’ is waarschijnlijk zo omdat de Engelse zin over ‘scam’ > spreekt. Ondanks dat er in het label ‘phishing’ staat. TB: <!ENTITY phishingBarMessage2.label "This message may be a scam."> SM: <!ENTITY phishingBarMessage.label "&brandShortName; thinks this message might be an email scam."> Als TB over scam spreekt en SM over phishing, dan lijkt het me verstandig dat verschil aan te houden. De zinnen wijken soms ook iets van elkaar af en hebben dan een groot verschil in betekenis. In dit geval gaat het in beide gevallen over een scam dus ik zou dat gewoon aanhouden, overigens ook omwille van gebruikers van zowel SM als TB. > Ook: phishing is een scam, maar dat geldt niet andersom, het is een subset. Goed punt. > Kunnen we niet gewoon gaan voor een Nederlandse term? Oplichting, frauduleus, > bedrog, zwendel, misleiding… er zijn zoveel woorden die wel zouden passen. Ik had gehoopt dat het begrip scam inmiddels wat meer is ingeburgerd. Websites als security.nl hanteren de term gewoon, Microsoft lijkt deze te willen vermijden. Het probleem is echter dat er gewoon geen vertaling voor is. Een scam is immers een ‘vorm van oplichting’ (en om die reden ook al niet vervangbaar door ‘phishing’), maar als zelfstandig naamwoord is het niet vervangbaar door bv. (de) zwendel of misleiding. We kunnen er dus wel ‘omheen gaan schrijven’, maar iets zegt me dat het letterlijke scam toch duidelijker is. Denk bv. ook aan de welbekende 419-scams, dit is niet vervangbaar. Ik pleit er dus voor het vooralsnog te behouden. Wellicht dat scam, net als spam, in een volgende versie net zo gewoon is. Dat het niet in Van Dale staat is dan bij hoge uitzondering. Commentaar n.a.v. comment 51 volgt nog.
Depends on: 468311
Depends on: 555524
Comment on attachment 444238 [details] [diff] [review] SeaMonkey keys toegepast op nl-central. Ik hoef je vraag per mail dus niet meer te beantwoorden ;-) stage-sj dashboard is tegenwoordig de beste plek om te kijken (al klopt de "oude" dashboard wat betreft seamonkey nog wel)
Attachment #444238 - Attachment is obsolete: true
Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 SeaMonkey/2.0.4 In het paginacontextmenu van de browser staat "Deze pagina verzendenSend this page ..." In file C:\mozdev\nl\suite\chrome\browser\mailNavigatorOverlay.dtd staat echter de juiste string: <!ENTITY contextSendThisPage.label "Deze pagina verzenden…"> Ik kan dit niet verklaren.
(In reply to comment #59) > Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1.9) Gecko/20100317 > Lightning/1.0b1 SeaMonkey/2.0.4 > > In het paginacontextmenu van de browser staat "Deze pagina verzendenSend this > page ..." > > In file C:\mozdev\nl\suite\chrome\browser\mailNavigatorOverlay.dtd staat echter > de juiste string: > <!ENTITY contextSendThisPage.label "Deze pagina verzenden…"> > > Ik kan dit niet verklaren. Dit is verbeterd op 3 april maar versie 2.0.4 is van daarvoor. Als het goed is is het in de komende 2.0.5 opgelost
attachment 446926 [details] [diff] [review] of bug 468311 heb ik toegepast en bijna alle problemen met de hand opgelost. Alleen suite/chrome/mailnews/compose/composeMsgs.properties en suite/chrome/mailnews/localMsgs.properties zijn zodanig verandert dat daar nog even door jullie naar gekeken moet worden
https://l10n-stage-sj.mozilla.org/shipping/dashboard?locale=nl&tree=weave is groen en gaat dus mee in de rc builds. "we will include any locales that are green on the dashboard as of Monday, May 24, 2010 at 15:00:00 UTC." meld even in deze bug wanneer jullie hem getest hebben en ik een sign-off kan doen
(In reply to comment #62) > https://l10n-stage-sj.mozilla.org/shipping/dashboard?locale=nl&tree=weave > is groen en gaat dus mee in de rc builds. > > "we will include any locales that are green on > the dashboard as of Monday, May 24, 2010 at 15:00:00 UTC." > > meld even in deze bug wanneer jullie hem getest hebben en ik een sign-off kan > doen verkeerde bug. sorry voor de bugspam, dat krijg je als je meerdere tabbladen met bugs heb open staan
(In reply to comment #61) > attachment 446926 [details] [diff] [review] of bug 468311 heb ik toegepast en bijna alle problemen met > de hand opgelost. Alleen suite/chrome/mailnews/compose/composeMsgs.properties > en suite/chrome/mailnews/localMsgs.properties zijn zodanig verandert dat daar > nog even door jullie naar gekeken moet worden Bij deze.
Comment on attachment 446967 [details] [diff] [review] Wijzigingen in composeMsgs.p en LocalMsgs.p toegepast
Attachment #446967 - Attachment is obsolete: true
Ik merk in OpenOffice.org 3.2.1 Macintosh dat de letter voor vetgedrukt V is, voor cursief C en voor onderlijnt O. In SeaMonkey 2.0.6 staat voor vetgedrukt B, voor cursief I en voor onderlijnt U. Dit dient dus nog aangepast te worden. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; nl; rv:1.9.1.11) Gecko/20100701 SeaMonkey/2.0.6
(In reply to comment #66) > Dit dient dus nog aangepast te worden. Daar ben ik nog niet zo zeker van. Wat is de relatie tot OpenOffice.org en waarom moet de gekozen benadering in OOo van toepassing zijn op SeaMonkey? Hoe is dit in Thunderbird en andere Mozilla-programma's opgelost? Overigens eindigt het woord onderlijnd op een d.
Het antwoord is (inderdaad) zeer waarschijnlijk negatief, maar laten we eerst eens afwachten of Samuël de sneltoetsen of de symbolen bedoelt (zie ook bug 549062#c12).
Ik denk dat hij het over de Cmd keys heeft (Ctrl+ of Cmd+) maar wat ik niet snap is dat het in Ooo 3.2 (windows) ook (zoals het hoort) Ctrl+B is voor vet, waarom zou het anders zijn in 3.2.1 mac. Om een lang verhaal kort te maken, Cmd keys worden niet vertaald in zijn in alle mozillaproducten hetzelfde (en in microsoft office, linux tekstverwerkers etc). Dus als het hierom gaat zal het niet aangepast worden.
Ook in 3.2.1 windows is het standaard dus ik ben heel benieuwd waar er op gedoeld wordt
Terzijde: ik herinner me van eerdere versies van OOo dat de command keys in de NL versie V, C en O waren (evenals in WordPerfect voor Linux) maar in de huidige NL 3.2.1 voor Windows is het de gebruikelijke B, I en U. Voor de SeaMonkey-vertaling is dit irrelevant.
Ik bedoel die in de opmaakwerkbalk.
Die worden niet gewijzigd.
(In reply to comment #72) > Ik bedoel die in de opmaakwerkbalk. Ah, dat heeft niks met de vertaling te maken van de UI maar met het thema wat je gebruikt. Zoek op https://addons.mozilla.org/nl/seamonkey/themes/ naar een thema met "nederlandse" knoppen
de sign off voor seamonkey 2.1 beta 1 is nu open.....
Sm 2.1 zal een gegevensbeheerder hebben waarin opgeslagen wachtwoorden, formuliergegevens, cookies en dergelijke centraal kunnen worden beheerd. In de vertaalbestanden wordt het begrip 'domain' gebruikt. Voorbeeld: <!ENTITY domain.search.placeholder "Search Domains">. Hoe wordt dit vertaald in andere producten?
Dat hangt een beetje van de context (en Engelse term, dus niet de entity) af, maar meestal is dit gewoon ‘domein’. Ben jij overigens nog van plan de tree groen te maken, of…?
Op het eerste gezicht ziet de patch er aardig uit. Wel zijn er wat kleine foutjes, maar wat mij betreft kan deze worden toegepast. Kijk niet gek op als er nog een patch volgt (dit betreft dan waarschijnlijk wat infinitieven, gekrulde aanhalingstekens, stijlzaken en enkele keys.) Ook zag ik nog een paar onvertaalde bestanden. Niek, zou je in het vervolg patches voor Help-bestanden apart willen opstellen/plaatsen? Dit hebben we tot nu toe gescheiden gehouden en maakt e.e.a. wat makkelijker. Verder een vriendelijk verzoek zaken die je anders zou willen vertalen dan dat ze al voorkomen eerst voor te stellen; dit om het overzicht te houden, een heen-en-weer van wijzigingen te voorkomen en overeengekomen verbeteringen ook op andere producten te kunnen toepassen.
(In reply to comment #79) > Niek, zou je in het vervolg patches voor Help-bestanden apart willen > opstellen/plaatsen? Dit hebben we tot nu toe gescheiden gehouden en maakt > e.e.a. wat makkelijker. > https://bugzilla.mozilla.org/show_bug.cgi?id=508742 > Verder een vriendelijk verzoek zaken die je anders zou willen vertalen dan dat > ze al voorkomen eerst voor te stellen; dit om het overzicht te houden, een > heen-en-weer van wijzigingen te voorkomen en overeengekomen verbeteringen ook > op andere producten te kunnen toepassen. hier sluit ik me bij aan, zeker als het een verbetering is die we moeten doorvoeren in de andere producten.
Comment on attachment 485611 [details] [diff] [review] Patch voor https://l10n-stage-sj.mozilla.org/dashboard/compare?run=100845 toegepast met fouten in de volgende bestanden, waarschijnlijk omdat ik de afgelopen dagen thunderbird bijgewerkt heb en daarbij ook wat mailnews bestanden. kijk er even naar. suite/chrome/common/profile/profileSelection.dtd.rej suite/chrome/mailnews/junkMailInfo.dtd.rej suite/chrome/mailnews/messenger.dtd.rej suite/chrome/mailnews/pref/am-copies.dtd.rej suite/chrome/mailnews/pref/am-main.dtd.rej suite/chrome/mailnews/smime/am-smime.properties.rej
Attachment #485611 - Attachment is obsolete: true
(In reply to comment #81) > Comment on attachment 485611 [details] [diff] [review] > Patch voor https://l10n-stage-sj.mozilla.org/dashboard/compare?run=100845 > > toegepast met fouten in de volgende bestanden, waarschijnlijk omdat ik de > afgelopen dagen thunderbird bijgewerkt heb en daarbij ook wat mailnews > bestanden. kijk er even naar. > > suite/chrome/common/profile/profileSelection.dtd.rej > suite/chrome/mailnews/junkMailInfo.dtd.rej > suite/chrome/mailnews/messenger.dtd.rej > suite/chrome/mailnews/pref/am-copies.dtd.rej > suite/chrome/mailnews/pref/am-main.dtd.rej > suite/chrome/mailnews/smime/am-smime.properties.rej suite/chrome/mailnews/messenger.dtd heb ik met de hand hersteld, alles uit de patch is nu gebeurt
heb nog even gekeken naar profileSelection.dtd en die verandering was al doorgevoerd (http://hg.mozilla.org/l10n-central/nl/rev/da80ab60f466) via een patch uit bug 468311 (verbeteringen in een branch (1.9.1) pas ik in principe ook altijd op de trunk (central) toe) op 15 oktober. zorg er voor dat je een actuele versie hebt voordat je een patch maakt.
Corrigeert wat zaken uit de vorige patch, maakt enkele ongedaan en andere uniform/consistent, verwijdert tabs/witregels, vertaalt places.properties en maakt a.h.g.i. de tree groen. Tim: welke actie is er eigenlijk nodig om 2.1 mee te laten gaan in de bèta’s/final?
Attachment #487239 - Flags: review?(niekdekker)
(In reply to comment #84) > > Tim: welke actie is er eigenlijk nodig om 2.1 mee te laten gaan in de > bèta’s/final? zorgen dat hij groen blijft :-). Als het goed is gaat hij de eerst volgende beta mee.
(In reply to comment #84) > Created attachment 487239 [details] [diff] [review] > Correcties/edits na attachment 485611 [details] [diff] [review] > > Corrigeert wat zaken uit de vorige patch, maakt enkele ongedaan en andere > uniform/consistent, verwijdert tabs/witregels, vertaalt places.properties en > maakt a.h.g.i. de tree groen. zie https://bugzilla.mozilla.org/show_bug.cgi?id=468311#c73 voor een opmerking die ook voor deze patch geldt.
(In reply to comment #86) > zie https://bugzilla.mozilla.org/show_bug.cgi?id=468311#c73 voor een opmerking > die ook voor deze patch geldt. Zie https://bugzilla.mozilla.org/show_bug.cgi?id=468311#c74 voor een antwoord daarop.
Ik wilde voorstellen om, zoals ooit al eens is voorbijgekomen, Gereedschappen in de menubalk te wijzigen naar Hulpmiddelen of Extra. Hulpmiddelen is de gangbare vertaalde term voor Tools (los van het enkelvoudverhaal voor Gereedschap, en doorgaans in teksten), maar er is al eens voorgesteld om in de menubalk net als bij FF/TB/SB (en IE?) Extra te hanteren, zonder dat daar iets mee is gedaan. Tim is het hier als het goed is mee eens. Meningen/bezwaren?
Ik weet momenteel niet precies wanneer de volgende beta uitgegeven wordt, maar als we meewillen in het beta programma is het handig om te proberen zo veel mogelijk synchroon te blijven met de en-US versie. Niek wil je patch bekijken en een ok geven? (In reply to comment #88) Tim is het hier als het goed is mee eens. inderdaad
(In reply to comment #88) > Ik wilde voorstellen om, zoals ooit al eens is voorbijgekomen, Gereedschappen > in de menubalk te wijzigen naar Hulpmiddelen of Extra. Hulpmiddelen is de > gangbare vertaalde term voor Tools (los van het enkelvoudverhaal voor > Gereedschap, en doorgaans in teksten), maar er is al eens voorgesteld om in de > menubalk net als bij FF/TB/SB (en IE?) Extra te hanteren, zonder dat daar iets > mee is gedaan. Tim is het hier als het goed is mee eens. Meningen/bezwaren? mee eens
(In reply to comment #90) > (In reply to comment #88) > > Ik wilde voorstellen om, zoals ooit al eens is voorbijgekomen, Gereedschappen > > in de menubalk te wijzigen naar Hulpmiddelen of Extra. Hulpmiddelen is de > > gangbare vertaalde term voor Tools (los van het enkelvoudverhaal voor > > Gereedschap, en doorgaans in teksten), maar er is al eens voorgesteld om in de > > menubalk net als bij FF/TB/SB (en IE?) Extra te hanteren, zonder dat daar iets > > mee is gedaan. Tim is het hier als het goed is mee eens. Meningen/bezwaren? > > mee eens en hoe staat het met de patch van Ton, Niek. Ik zou hem namelijk graag willen dat seamonkey 2.1 ook groen wordt en dat we meegaan in het beta programma
review op 50%, verwacht hem zaterdag en gaat mee in beta programma
Attachment #487239 - Flags: review?(niekdekker) → review+
Comment on attachment 487239 [details] [diff] [review] Correcties/edits na attachment 485611 [details] [diff] [review] toegepast
Attachment #487239 - Attachment is obsolete: true
Nog een paar strings en dan is de nl versie helemaal actueel. Dat brengt mij bij het volgende. Hoe gaan we de sign-off doen. Geef ik een sign-off wanneer de build groen is en ik de laatste versie gedraaid heb (alleen visueel de ui)? Of Gebruikt een van jullie de laatste nightly en geeft het teken tot sign-off als die build goed getest is?
Attached patch Update 20101118 (obsolete) — — Splinter Review
Moet (op het toolkit-bestand na) de tree groen maken en bevat de kleine aanpassing genoemd in bug 468311 comment 72.
(In reply to comment #94) > Nog een paar strings en dan is de nl versie helemaal actueel. Dat brengt mij > bij het volgende. Hoe gaan we de sign-off doen. Geef ik een sign-off wanneer de > build groen is en ik de laatste versie gedraaid heb (alleen visueel de ui)? Of > Gebruikt een van jullie de laatste nightly en geeft het teken tot sign-off als > die build goed getest is? Ik gebruik SM 2.1pre niet dagelijks en weet niet of ik de ‘groenstatus’ in het oog kan houden. Maar ervan uitgaande dat een groene build lokaal al is getest na zijn laatste wijzigingen zou je inderdaad alleen op de eigen controle kunnen afgaan. Misschien dat Niek 2.1 gebruikt?
Attachment #491675 - Flags: review?(niekdekker)
Attachment #491675 - Flags: review?(niekdekker) → review+
Attached patch Gereedschappen -> Extra + nits (obsolete) — — Splinter Review
… plus 2 nits in commentaarregels. Het lijkt me logisch dat we ‘Extra’ vanaf 2.1 gebruiken, dus niet meer aanpassen in 2.0. Of toch wel?
Attachment #492107 - Flags: review?(niekdekker)
Attachment #492120 - Flags: review?(niekdekker)
Attached patch Search plugins (obsolete) — — Splinter Review
Waren blijkbaar vergeten, en de oude list.txt schijnt ervoor te zorgen dat de nightly builds niet worden gemaakt. Net als enkele andere talen (de, es) heb ik hier alleen Wikipedia-nl gebruikt (=kopie uit FF); de overige komen vanzelf uit en-US. Zie ook Kairo’s bericht in de l10n-nieuwsgroep.
Attachment #492179 - Flags: review?(niekdekker)
Attachment #492120 - Flags: review?(niekdekker) → review+
(In reply to comment #97) > > Het lijkt me logisch dat we ‘Extra’ vanaf 2.1 gebruiken, dus niet meer > aanpassen in 2.0. Of toch wel? Ik zou het ook alleen aanpassen in 2.1. en 2.0 laten zoals het is.
(In reply to comment #99) > Created attachment 492179 [details] [diff] [review] > Search plugins > > Waren blijkbaar vergeten, en de oude list.txt schijnt ervoor te zorgen dat de > nightly builds niet worden gemaakt. Net als enkele andere talen (de, es) heb ik > hier alleen Wikipedia-nl gebruikt (=kopie uit FF); de overige komen vanzelf uit > en-US. Zie ook Kairo’s bericht in de l10n-nieuwsgroep. goeie!! Ik zal deze patch toepassen zonder review van Niek, omdat het niet UI verandering is.
Comment on attachment 491675 [details] [diff] [review] Update 20101118 toegepast
Attachment #491675 - Attachment is obsolete: true
Comment on attachment 492179 [details] [diff] [review] Search plugins toegepast
Attachment #492179 - Attachment is obsolete: true
Attachment #492179 - Flags: review?(niekdekker)
Comment on attachment 492120 [details] [diff] [review] Recente aanpassingen in CC en fixes toegepast
Attachment #492120 - Attachment is obsolete: true
Attached patch Update 26-11 (obsolete) — — Splinter Review
Moet tree groen maken (als de reviews tenminste niet te lang duren… Niek?) en bevat enkele gemiste commentaarwijzigingen (die immers niet op het dashboard verschijnen).
Attachment #493414 - Flags: review?(niekdekker)
Attachment #493414 - Flags: review?(niekdekker) → review+
Comment on attachment 493414 [details] [diff] [review] Update 26-11 toegepast
Attachment #493414 - Attachment is obsolete: true
Wat doen we met de 2 openstaande patches?
Gekopieerd van browser.properties (firefox) deze patch maakt seamonkey 21x weer groen
Attachment #495944 - Flags: review?(niekdekker)
Tonnes, heb jij dezelfde formulering gebruikt of.. ?
Uitgaande van de vergelijkbare string in /toolkit zou ik de lange zin inderdaad zo formuleren, hoewel het qua woordvolgorde misschien iets beter zou kunnen. Ook zie ik voor ‘restart’ hier en daar wat inconsistent gebruik (herstarten / opnieuw opstarten), hoewel dat niet per definitie erg hoeft te zijn. Maar wellicht kunnen alle restart-strings eens op de schop. ‘Herstart nu’ is natuurlijk onjuist, want we gebruiken standaard immers infinitief / hele werkwoord en nooit gebiedende wijs, m.u.v. tekst die aan een gebruiker is gericht (vaak herkenbaar aan een punt), weet je nog? ;) De patch zou dan zo worden. Er zit ook nog een ander foutje in verwerkt, dat een voorbeeld is van de genoemde inconsistentie en samen met de recente wijzigingen doet vermoeden dat er nog steeds een grondige controle t.o.v. 2.0 nodig is. Kunnen de reviews overigens wat sneller? Ik begrijp eerlijk gezegd niet waarop zo lang wordt gewacht, ondanks herhaald verzoek.
Attachment #496019 - Flags: review?(niekdekker)
> ‘Herstart nu’ is natuurlijk onjuist, want we gebruiken standaard immers > infinitief / hele werkwoord en nooit gebiedende wijs, m.u.v. tekst die aan een > gebruiker is gericht (vaak herkenbaar aan een punt), weet je nog? ;) > deze opmerking heb ik nu ook doorgevoerd in firefox (http://hg.mozilla.org/l10n-central/nl/rev/cb67ff87823e)
Attachment #495944 - Attachment is obsolete: true
Attachment #495944 - Flags: review?(niekdekker)
Comment on attachment 496019 [details] [diff] [review] Notify when installing a lightweight theme but e.g. Modern is current which means that a restart is needed - v2 toegepast
Attachment #496019 - Attachment is obsolete: true
Attachment #496019 - Flags: review?(niekdekker)
Assignee: niekdekker → dutch.nl
Attached patch Update 20101221 (obsolete) — — Splinter Review
Attachment #499194 - Flags: review?(niekdekker)
Attached patch Update 20101221 v2 (obsolete) — — Splinter Review
Aangepaste versie met 2 recente wijzigingen voor groene tree en 2 aangetroffen foutjes n.a.v. Fx4. Overigens heb ik de hoop voor reviews vóór de jaarwisseling inmiddels laten varen, maar hoop (en verwacht) wel dat dit in het nieuwe jaar beter gaat.
Attachment #499194 - Attachment is obsolete: true
Attachment #500546 - Flags: review?(niekdekker)
Attachment #499194 - Flags: review?(niekdekker)
Niek, hoever sta je met de review van de patches, ik zou graag de boel willen bijwerken zodat we weer een complete build hebben
Attached patch Update 20110108 (obsolete) — — Splinter Review
Vervangt 20101221, bijgewerkt tot vandaag en bevat 2 nits n.a.v. Fx4.
Attachment #500546 - Attachment is obsolete: true
Attachment #502305 - Flags: review?(niekdekker)
Attachment #500546 - Flags: review?(niekdekker)
Attached patch Update 20110108 v2 (obsolete) — — Splinter Review
Bijgewerkt t/m vandaag.
Attachment #502305 - Attachment is obsolete: true
Attachment #504245 - Flags: review?(niekdekker)
Attachment #502305 - Flags: review?(niekdekker)
Attachment #504245 - Flags: review?(niekdekker) → review+
Wat doen we met attachment 492107 [details] [diff] [review] (van 20 nov)?
Comment on attachment 492107 [details] [diff] [review] Gereedschappen -> Extra + nits Niek is gestopt met seamonkey. Ik zal het voorlopig weer overnemen. hopelijk meld zich snel weer iemand die het weer overneemt van mij.
Attachment #492107 - Flags: review?(niekdekker) → review+
Comment on attachment 492107 [details] [diff] [review] Gereedschappen -> Extra + nits toegepast: http://hg.mozilla.org/l10n-central/nl/rev/2be5953a996a
Attachment #492107 - Attachment is obsolete: true
Ik schrok even van deze edit: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/3cb3331ea0bb#l1.22 "Accentueer web pagina's met een hoge verbindingsbeveiliging"> Dit is nou een prachtig voorbeeld van maar liefst 3 (!) fouten (die we allang niet meer mogen maken) in één regel. Tim, zou je hier iets zorgvuldiger mee om kunnen gaan? Ook zie ik het liefst dat correcties op TB die ook op SM van toepassing zijn, hierop worden toegepast. SM is sinds mijn laatste controle vooral door dit soort fouten sterk vervuild, en dat is nergens voor nodig…
SeaMonkey 2.30 is klaar voor controle
Attached patch niet-ingebed-seamonkey.patch (obsolete) — — Splinter Review
Patch om niet-ingebed in extern te veranderen
Comment on attachment 8491446 [details] [diff] [review] niet-ingebed-seamonkey.patch toegepast http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/7c3a9f1bb468 dank!
Attachment #8491446 - Attachment is obsolete: true
seamonkey 2.32 is klaar voor controle
1) Tim, zou je misschien je eigen recente edits nog eens zorgvuldig willen nalopen? In bv. http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/75916f7c9a26 zie ik fouten die tegenwoordig absoluut niet meer kunnen, zowel in nieuwe als in bestaande strings eronder. Een eventuele controle sinds mijn laatste gaat op deze manier heel veel moeite kosten… 2) Waarom gaat de titel van deze bug eigenlijk (nog) over central; moet of kan dit niet beter aurora zijn? Ook graag net als de overige bugs [nl] in de titel toevoegen als dit zou worden aangepast omwille van consistentie en eventuele berichtenfilters.
Wat is “Blijk blokkeren”? En waarom zie ik in dezelfde changeset en hetzelfde bestand zaken als gebiedende wijs in opties (Waarschuw me, schakel deze functie…), gevolg worden (worden achteraan), ik geeft, websites kan, vraag me, etc. etc.? En dit is maar 1 bestand… @Tim: het lijkt misschien een beetje een uiting van frustratie, maar nog maar een keer en hopelijk voor de laatste keer de dringende vraag of je wat secuuurder wilt werken, je aan afspraken uit het verleden wilt houden, van fouten en reminders wilt leren, edits/verbeteringen uit bv. TB wilt overnemen of de bron daarvan simpelweg als voorbeeld wilt gebruiken, en vooral na iedere edit 1 of 2 keer goed te lezen wat je hebt ingetypt voordat je iets commit. Het is werkelijk tenenkrommend hoe SM er nu uitziet.
Het porten van Tb patches naar seamonkey kost veel tijd en daar heb ik nog geen tijd voor gehad (staat op mijn lijst). als je wilt dat het snel verbeterd, ga je gang om een patch aan te bieden.
Sorry maar jij refereert naar een changeset van Sat, 11 May 2013 14:32:30 +0200?
Klopt. Bij opzoeken van deze string via Transvision zag ik dat hij ook in SM zat, maar als "Blijk blokkeren", en dat daarnaast in wat ik dacht dezelfde maar naar nu blijkt een andere meer recente changeset (http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/9c104288ef6e) een hoop andere fouten in SM zitten. Geen echte verrassing, maar ik schrok wel van de hoeveelheid. Dat de genoemde fout al in 2013 is geïntroduceerd is niet zo relevant maar vind ik des te erger, vooral omdat deze zaken niemand, maar vooral ook degene die ze erin heeft gezet, zijn opgevallen. Toegegeven: SM wordt nog nauwelijks gebruikt en klachten over vertaalfouten horen we dus niet of nauwelijks, maar ik vind niet dat dit een rechtvaardiging is voor een mindere kwaliteit dan die van de andere producten, omdat we nu eenmaal met identieke strings en bestanden werken, en niet in de minste plaats omdat we worden geacht inmiddels wat expertise in huis te hebben. Ik ben overigens op korte termijn niet van plan een patch te maken, hoewel ik het niet wil uitsluiten. Beter is een volledige controle die dan zelfs over een nog langere perdiode moet plaatsvinden dan die voor TB. Nog beter vind ik het als degene die verantwoordelijk is voor de fouten sinds laten we zeggen 16-01-2011 zelf de boel volledig controleert en de bron bv. naast die van FF/TB of zelfs SM 1.x legt en herstelt, uiteraard om anderen te ontlasten, maar ook nog steeds in de hoop dat van fouten wordt geleerd.
Ik zorg er alleen voor dat de veranderingen uit de engelse versie worden toegepast (zolang er geen nieuwe beheerder is gevonden) en verwacht van de gemeenschap dat ze het controleren/verbeteren (natuurlijk dien ik het ook zonder fouten te doen, maar soms ben ik te snel) ik kijk verder niet naar de bestanden en verbeter alleen fouten die ik toevallig tegen kom (daarvoor heb ik het veel te druk). dat fouten bijna 2 jaar bestaan zegt helaas genoeg over de interesse van de gemeenschap in de Nederlandse versie van Seamonkey. Misschien moeten we besluiten om de komende versies niet in het Nederlands uit te geven, dan staat er misschien iemand op die het op zich wilt nemen.
Ik gebruik SeaMonkey eigenlijk niet zelf, alleen om te testen of mijn extensie het doet en dan meestal in het Engels (net als Thunderbird overigens :-)), maar als jullie erg omhoog zitten met SeaMonkey wil ik wel kijken of ik dat er bij kan doen. Ik neem aan dat veel van de strings rechtstreeks van Firefox komen en dat het niet veel meer werk is dan Thunderrbird, klopt dat?
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #133) > Ik gebruik SeaMonkey eigenlijk niet zelf, alleen om te testen of mijn > extensie het doet en dan meestal in het Engels (net als Thunderbird > overigens :-)), maar als jullie erg omhoog zitten met SeaMonkey wil ik wel > kijken of ik dat er bij kan doen. Ga je gang :) > > Ik neem aan dat veel van de strings rechtstreeks van Firefox komen en dat > het niet veel meer werk is dan Thunderrbird, klopt dat? Inderdaad zijn veel strings afkomstig uit Firefox en Thunderbird maar let wel op, de seamonkey-programmeurs hebben nog wel eens de neiging om een string wat te veranderen t.o.v Thunderbird/Firefox maar wel de zelfde entitynaam te houden. Zomaar 1 op 1 kopiëren omdat de entity het zelfde is kan dan dus niet zomaar altijd.
Assignee: dutch.nl → o.e.ekker
QA Contact: dutch.nl
Summary: l10n-central/nl Seamonkey → [nl] mozilla-aurora/nl seamonkey
Attached patch controle.diff (obsolete) — — Splinter Review
(In reply to Ton from comment #128) > Wat is “Blijk blokkeren”? Naar aanleiding van deze opmerking heb ik de laatste patches gecontroleerd en er nog wat typefouten uit gehaald. Deze zitten zowel in browser als in calendar, mail, mobile en suite, dus ik weet niet goed wie deze diff kan toepassen.
+++ b/browser/chrome/browser/browser.dtd Liever geen wijzigingen aan FF in deze bug. -<!ENTITY readingList.sidebar.emptyText "Voeg artikelen toe aan uw leeslijst om ze te bewaren voor later en ze weer gemakkelik terug te vinden als u ze nodig heeft."> +<!ENTITY readingList.sidebar.emptyText "Voeg artikelen toe aan uw leeslijst om ze voor later te bewaren en ze weer gemakkelijk terug te vinden als u ze nodig heeft."> De verplaatsing is terecht, maar er staat 3 x 'ze' in deze zin, evenals 'u heeft' (altijd 'u hebt') . Ik zou er het volgende van maken: "Voeg artikelen toe aan uw leeslijst om deze voor later te bewaren en weer gemakkelijk terug te vinden als u ze nodig hebt." Het stukje eronder deugt ook nog niet: <!-- Pre-landed string for bug 1123525 --> <!ENTITY readingList.sidebar.delete.tooltip "Verwijder dit uit uw leeslijst"> ->> Dit uit uw leeslijst verwijderen (tooltips gebruiken geen gebiedende wijs) <!-- Pre-landed strings for bug 1123519 --> <!ENTITY readingList.sidebar.add.label "Aan leeslijst toevoegen"> ->> Toevoegen aan leeslijst +++ b/browser/pdfviewer/viewer.properties printing_not_supported=Waarschuwing: afdrukken wordt niet volledig ondersteund door deze browser. -printing_not_ready=Warning: PDF is niet volledig geladen om af te drukken. +printing_not_ready=Waarschuwing: PDF is niet volledig geladen om af te drukken. Ik zou er meteen 'voor afdrukken' van maken. (en: for printing) +++ b/calendar/chrome/calendar/calendar-extract.properties Liever ook geen wijzigingen aan calendar in een patch met iets anders, dat is ook een apart onderdeel (met aparte bug). Er klopt daarin trouwens nog meer niet; ik neem het mee. +++ b/mail/chrome/messenger/messenger.dtd Mail qua patches ook liever gescheiden houden. +++ b/mobile/android/base/android_strings.dtd Hetzelfde geldt voor mobile. Hoe vervelend het soms ook is, we bieden ze gescheiden aan voor archiveringsdoeleinden (de aparte bugs zijn er niet voor niets). +++ b/suite/chrome/common/notification.properties -MixedDisplayContentMessage=U hebt een pagina opgevraagd die slechts gedeeltelijk versleuteld is en zal afluisteren niet voorkomen. +MixedDisplayContentMessage=U hebt een pagina opgevraagd die slechts gedeeltelijk versleuteld is en afluisteren niet zal voorkomen. -> die slechts gedeeltelijk is versleuteld en afluisteren niet zal voorkomen. (In Engels is dat laatste tegenwoordige tijd, maar toch.) SecurityKeepBlocking.label=Blijk blokkeren +SecurityKeepBlocking.label=Blijf blokkeren -> Blijven blokkeren (computeractie/knoptekst, dus géén gebiedende wijs) 1) In het algemeen: misschien is het beter te wachten met patches voor FF/TB/Fennec tot de boel is bijgewerkt, omdat zaken anders gaan conflicteren, niet werken of al zijn verwijderd/vervangen/gecorrigeerd. Het is dus van belang dat dingen tijdig worden bijgewerkt (en niet pas in de laatste week), omdat nu eenmaal controle daarop nodig is, zowel qua toegepaste wijzigingen/patches als qua testen door gebruikers, wat er vaak niet (meer) van komt. 2) Gebiedende wijs wordt _uitsluitend_ gebruikt om de gebruiker aan te spreken.
Ik wacht wel even tot de rest is bijgewerkt, misschien nemen de verantwoordelijken voor de respectievelijke onderdelen (browser/calendar/mail/mobile) hun stukje wel over. En anders zal ik de diffs in de juiste bug aanleveren.
Comment on attachment 8579202 [details] [diff] [review] controle.diff Patch toegepast op Firefox, Thunderbird, Lightning en SeaMonkey. Diffs gepost bij bug 653758 (Firefox) en bug 722704 (Fennec/Mobile)
Attachment #8579202 - Attachment is obsolete: true
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #140) > > Patch toegepast op Firefox, Thunderbird, Lightning en SeaMonkey. > Diffs gepost bij bug 653758 (Firefox) en bug 722704 (Fennec/Mobile) Zou je dergelijke gecombineerde patches z.s.m. obsolete kunnen maken en opsplitsen, en daarna liever ook geen dingen schrijven als "Patch toegepast op Firefox, Thunderbird, Lightning en SeaMonkey", want ik schrok me even een hoedje. Het wordt een beetje een rommeltje zo, ook qua uitzoeken wat er nu wel en niet is toegepast, en de bug is alleen voor SM…
Ik heb de patch juist op obsolete gezet en opgesplitst. Het commentaar daarbij had inderdaad duidelijker gekund, excuses voor je hartverzakking.
SeaMonkey 2.36a2 is klaar voor controle: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/dd1870450c5f (Kijk ook even naar viewFallbackCharset.desc. Deze eindigt op 'kan declareren', maar ik denk eigenlijk dat 'declareert' beter is.)
Controle kan nog even duren, maar ik kan hier kort over zijn, of dat proberen. :) Strings in SM zijn zoals je hebt gemerkt nagenoeg identiek aan die in FF/TB, hier en daar een kleine uitzondering daargelaten, zoals hier. Wat controles/eisen/verbeteringen betreft hebben die, althans nadat ik eraan heb gewerkt (=alle verbeteringen van FF/TB tot ongeveer 2011 toegepast op de laatste SM 1.x en nog heel even SM 2 gevolgd) niet meer plaatsgevonden, en ik sluit niet uit dat daarna bij het periodieke bijwerken ervan niet naar de vertaling in FF/TB is gekeken, getuige ook de changeset van de oude strings - http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/diff/e73b4e41c546/suite/chrome/common/pref/pref-languages.dtd . Het kan dus zijn dat je iets tegenkomt wat eigenlijk niet klopt of zelfs compleet fout is. We hebben het er al even over gehad en het makkelijkst is dat je de teksten/vertalingen uit FF en TB ernaast legt en overneemt, wel met behoud van de uitzonderingen; zo zal ik het ook doen bij een controle. Het is simpelweg de enige manier om er zeker van te zijn dat er overal kritisch naar is gekeken en de vertalingen optimaal zijn. Je zou bij elke stringwijziging in een bestand ook de rest ervan kunnen nalopen; zo kun je als je er toch bent e.e.a. al afvangen voor een controle. Voor iets als ‘fails to declare’ (kwam het gisteren nog tegen) zal in FF bewust zijn gekozen voor ‘niet kan aangeven’, dus het heeft eigenlijk geen zin om in SM ‘declareren’ te hanteren en je druk over te maken over de tijdsvorm. Sterker nog: de huidige tekst kan zelfs een anglicisme worden genoemd, want het heeft niets met de primaire betekenis (indienen van declaraties) te maken. Vergelijk het maar met bv. ‘identify’; dat kan ook iets ander betekenen (herkennen). Let ook altijd goed op wat er in de bron staat, want extra of juist weggelaten woorden kunnen veel betekenisverschil geven. Voor encoding achteraan kun je ook gewoon ‘codering’ gebruiken. De access key heb ik in FF van t naar T gewijzigd (was kleine t om nadruk aan tekenset te geven, zoals in en-US de C bij Character, maar de grote T lijkt zinvoller). FF: This text encoding is used for legacy content that fails to declare its encoding. Deze tekstcodering wordt gebruikt voor legacy-inhoud die geen eigen codering kan aangeven. SM: Used for legacy content that fails to declare its encoding. Huidig: Deze tekstcodering wordt gebruikt voor legacy-inhoud die geen eigen tekstcodering kan declareren. Zou moeten zijn: Wordt gebruikt voor legacy-inhoud die geen eigen codering kan aangeven. Waar ik nog benieuwd naar ben: in de big voor gezamenlijke mappen is saveAsChangeEncodingCmd2.label gewijzigd en heeft deze de key t gekregen. Dit bestand wordt blijkbaar alleen in SM gebruikt, dus controle daarvan is nodig. En verder staan er al langer dan een jaar 7 onjuiste of ontbrekende keys in SM, die kunnen ook worden aangepakt (zie Transvision).
Nieuwe/gewijzigde strings voor SeaMonkey 2.37a2: http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/1161ffd71390
SeaMonkey Aurora 2.42a2 is klaar voor controle: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/262c8766d360
SeaMonkey Aurora 2.43a2 is klaar voor controle: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/d282e16ebab1 Ik heb ook een paar van de laatste aanpassingen van Thunderbird overgenomen.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #154) > SeaMonkey Aurora 2.43a2 is klaar voor controle: > https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/d282e16ebab1 > diff --git a/suite/chrome/mailnews/messenger.dtd b/suite/chrome/mailnews/messenger.dtd > -<!ENTITY fileButton.label "Archiveren"> > +<!ENTITY fileButton.label "Verplaatsen"> filebutton.tooltip vergeten? > diff --git a/suite/chrome/mailnews/pref/am-copies.dtd b/suite/chrome/mailnews/pref/am-copies.dtd > <!ENTITY keepArchives.label "Berichtarchieven bewaren in:"> > -<!ENTITY keepArchives.accesskey "B"> > -<!ENTITY archiveHierarchyButton.label "Archiverenopties…"> > > -<!ENTITY archiveHierarchyButton.accesskey "A"> > -<!ENTITY archivesFolderOn.label "Map &quot;Archieven&quot; in on:"> > +<!ENTITY keepArchives.accesskey "r"> > +<!ENTITY archiveHierarchyButton.label "Archiveringsopties…"> > +<!ENTITY archiveHierarchyButton.accesskey "h"> > +<!ENTITY archivesFolderOn.label "Map “Archieven” in on:"> Houd er rekening mee dat SM een knop Help heeft met een accesskey (althans in de versie die ik nog heb staan), en dat je daarom in principe nooit de h kan gebruiken. Om het makkelijker te maken kun je dit ook in TB aanhouden zodat er m.b.t. keys geen verschillen tussen SM en TB zijn. Ook: "Map “Archieven” in on:" ? -> "Map ‘Archieven’ in:" Inderdaad, ik zou ook meteen andere aanhalingstekenns en eigenlijk alles in hetzelfde bestand meenemen als je er toch bent, dat scheelt weer een bestand bij een grote schoonmaak. > diff --git a/suite/chrome/mailnews/pref/pref-formatting.dtd b/suite/chrome/mailnews/pref/pref-formatting.dtd > -<!ENTITY convertPlain.label "Het bericht converteren naar platte tekst (bepaalde opmaak kan verloren gaan)"> > -<!ENTITY convertPlain.accesskey "c"> > -<!ENTITY sendHTML.label "Het bericht toch als opgemaakte tekst (HTML) verzenden (sommige mailprogramma’s kunnen het mogelijk niet weergeven)"> > -<!ENTITY sendHTML.accesskey "M"> > -<!ENTITY sendBoth.label "Het bericht in zowel platte tekst als HTML verzenden (grotere berichtgrootte)"> > -<!ENTITY sendBoth.accesskey "z"> > -<!ENTITY override.label "U kunt deze instellingen voor individuele berichten negeren door het menu Opties te gebruiken tijdens het opstellen van een bericht."> > +<!ENTITY convertPlain2.label "Het bericht converteren naar platte tekst (opmaak kan verloren gaan)"> > +<!ENTITY convertPlain2.accesskey "c"> > +<!ENTITY sendHTML2.label "Het bericht alleen als HTML verzenden (dit kan weergaveproblemen veroorzaken)"> > +<!ENTITY sendHTML2.accesskey "H"> > +<!ENTITY sendBoth2.label "Het bericht zowel als platte tekst als als HTML verzenden (grotere berichtgrootte)"> > +<!ENTITY sendBoth2.accesskey "z"> Uit http://hg.mozilla.org/releases/comm-aurora/rev/e6015d5e4091 > -<!ENTITY convertPlain.label "Convert the message to plain text (some formatting may be lost)"> > -<!ENTITY convertPlain.accesskey "C"> > -<!ENTITY sendHTML.label "Send the message as formatted text (HTML) anyway (some mail programs may not be able to display it)"> > -<!ENTITY sendHTML.accesskey "S"> > -<!ENTITY sendBoth.label "Send the message in both plain text and HTML (larger message size)"> > -<!ENTITY sendBoth.accesskey "n"> > -<!ENTITY override.label "You can override these settings for individual messages by using the Options menu while composing a message."> > +<!ENTITY convertPlain2.label "Convert the message to plain text (formatting may be lost)"> > +<!ENTITY convertPlain2.accesskey "C"> > +<!ENTITY sendHTML2.label "Send the message as HTML only (may cause display problems)"> > +<!ENTITY sendHTML2.accesskey "S"> > +<!ENTITY sendBoth2.label "Send the message as both plain text and HTML (larger size)"> > +<!ENTITY sendBoth2.accesskey "n"> Ik zou in sendHTML2.label ‘dit’ weglaten. En als in het Engels in sendBoth2.label wordt overgegaan naar ‘as’, wil dat niet zeggen dat dat in NL ook moet, hoewel TB dit al gebruikt bij het Engelse ‘in’ (en mogelijk niet zonder reden), dus wel OK, maar er staan nog wat te veel alsjes in. Om dat (‘zowel als ... als ...’) te vermijden kun je, net als in TB, ‘Bericht als platte tekst en HTML verzenden’ gebruiken. Ook vind ik ‘grotere grootte’ niet echt klinken; dit viel wat minder op door het oudere ‘berichtgrootte’ wat je hier ook nog hebt aangehouden. ‘Groter formaat’ lijkt me zinvoller en is voor deze string niet ongebruikelijk. Probeer i.h.a. zo min mogelijk verschillen met TB aan te houden als het kan, ook al zijn ze er in en-US wel, als ze tenminste te verklaren zijn. Andere tip: om dergelijke als-als- of in-on-foutjes te vermijden, is het handig om je eigen vertaling goed te controleren door de zinnen na de bewerkingen na te lezen en voor het committen nog eens goed in de workbench te kijken wat er bij een commit wordt verstuurd. > +<!ENTITY autoDowngrade.label "Het bericht automatisch als platte tekst versturen als er geen noemenswaardige opmaak aanwezig is (andere opties worden genegeerd)"> Algemeen: gemengd gebruik van versturen en verzenden stoort nogal. Ik denk dat TB in de meeste gevallen ‘verzenden’ gebruikt, en als dit niet zo is, moet hier eigenlijk nog eens goed op worden gecontroleerd, en dan bij voorkeur ‘verzenden’ gebruiken. > diff --git a/suite/chrome/mailnews/smime/am-smime.dtd b/suite/chrome/mailnews/smime/am-smime.dtd > -<!ENTITY securityHeading.label "Om ondertekende of versleutelde berichten te versturen dient u zowel een digitaal ondertekeningscertificaat als een versleutelingscertificaat te specificeren."> > +<!ENTITY securityHeading.label "Om ondertekende of versleutelde berichten te versturen, dient u zowel een digitaal ondertekeningscertificaat als een versleutelingscertificaat te specificeren."> Idem. Ook kan ‘specificeren’ in veel gevallen gewoon ‘opgeven’ zijn; een ander punt waarop de hele tekst nog eens kan worden gecontroleerd. > diff --git a/suite/chrome/mailnews/smime/msgSecurityInfo.properties b/suite/chrome/mailnews/smime/msgSecurityInfo.properties > -SIHeaderMismatch=Het e-mailadres dat is vermeld in het certificaat van de ondertekenaar verschilt van het e-mailadres dat is gebruikt om dit bericht te ondertekenen. Bekijk de details van het ondertekeningscertificaat om te zien wie dit bericht heeft ondertekend. > +SIHeaderMismatch=Het e-mailadres dat is vermeld in het certificaat van de ondertekenaar, verschilt van het e-mailadres dat is gebruikt om dit bericht te ondertekenen. Bekijk de details van het ondertekeningscertificaat om te zien wie dit bericht heeft ondertekend. Het plaatsen van de vereiste komma heeft hoofdzakelijk betrekking op twee werkwoorden die op elkaar volgen. Hier is te zien dat ‘is vermeld’ eigenlijk nog op de plek van het Engelse ‘listed’ staat. Ik wil daarmee niet zeggen dat de komma niet nodig is, maar je zou dan ook dat deel meteen naar voor de komma kunnen verplaatsen omwille van een meer Nederlandse woordvolgorde. Overigens zie ik nog steeds 7 onjuiste accesskeys voor SM in Transvision (zie ook comment 146). Het minste wat we kunnen doen is deze in orde maken. Verder popel ik om ook wat aan SM te doen, maar zolang er geen nightly’s van zijn hou ik me er nog niet mee bezig.
(In reply to Onno Ekker [:nONoNonO UTC+1] from comment #156) > Aanpassingen: > https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/4e013a2bd1cd > -PostToInsecureFromInsecureMessage=De informatie die u hebt ingevuld zal over een niet-beveiligde verbinding worden verzonden en kan gemakkelijk worden gelezen door derden.\nWeet u zeker dat u wilt doorgaan met het versturen van deze informatie? > +PostToInsecureFromInsecureMessage=De informatie die u hebt ingevuld zal over een niet-beveiligde verbinding worden verzonden en kan gemakkelijk worden gelezen door derden.\nWeet u zeker dat u wilt doorgaan met het verzenden van deze gegevens? Als je nou ‘informatie’ in de laatste zin vervangt, dan dus ook in de eerste. Overigens kun je voor deze zin als bron een vergelijkbare string gebruiken (zoek op ‘information you have entered’); er staat nog iets in wat niet klopt. Ook staan hierboven nog wat dingen die niet zijn verwerkt.
woordvolgorde bij "door derden worden gelezen" en komma en betere vertaling bij "zal %S geen adressen meer verzamelen": https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/b721ef750d58
SeaMonkey 2.44a2 is (hopelijk) klaar voor controle (compare-locales geeft 2 errors en 2 missing aan, maar dat komt volgens mij door (parse-)fout in devtools of dom): https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/0e9807e4cc88
Verbeteringen SeaMonkey n.a.v. controle consistency op transvision: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/ddc4b4c7ee51
SeaMonkey 2.46a2 Aurora is klaar voor controle: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/b1c5a71efade
SeaMonkey 2.47a2 Aurora is klaar voor controle: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/0b48bbe16082
Verbeteringen op SeaMonkey 2.47a2 na.v. controle Ton: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/750fcda42314
Verbeteringen seamonkey n.a.v. opmerkingen Tonnes: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/2019e35ce6096779e5873208d389f9524483de70 (commit bevat per ongeluk ook verbeteringen voor mail en editor)
Verbetering accesskeys en strings voor offline prefs en security prefs: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/827ec507790b9d8456e066006b26aacf84f13efe
Aanpassing menuitems bladwijzerbeheerder ivm consistentie met FX: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/3142531c27428f63529da33ff16523e84cca30cb
Opstellen ipv aanmaken en description/tooltip infinitief en verbeteren: https://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/54713fd23945f72ce74e215118fc25d26571890d
Depends on: sm-nl
Vanaf vandaag werken we weer in central, zie bug 1357709 (alias sm-nl), dus ik sluit deze bug.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: