468311 - l10n-mozilla-1.9.1/nl/ Seamonkey

Status: RESOLVED FIXED

(Mozilla Localizations :: nl / Dutch, defect)

Description

[Tim Maks van den Broek [:mad_maks]]

De bug voor de vertaling van Seamonkey 2

Comment 1

[DickB]

Attachment: nl.jar met voorgestelde wijzigingen

Ik heb op mac in de afgelopen dagen nl.jar bekeken en verschillende wijzigingen bij mijzelf aangebracht.
De meeste wijzigingen zijn van het type spelfout (verkeerde d's of dt's en zo) of ongelukkig gekozen formuleringen.

Er is een venster bij (preferences) dat iets te smal is. Het gaat om
locale - > nl -> communicator-platform -> mac -> pref -> platformPrefOverlay.dtd
width: 58em kan beter worden vervangen door width: 62em
Ik heb dit getest op het nieuwe thema "Seamonkey Default Theme" (gebouwd voor mac).

Mijn gewijzigde en "ingepakte" bestand nl.jar heb ik gekopieerd naar nl(dick).jar en stuur ik als bijlage mee.
Over het thema "Seamonkey Default Theme".
Als dit thema is ingesteld, worden zowel de pictogrammen als de bijbehorende tekst getoond ongeacht de keuze bij de voorkeursinstellingen.
Dit is ook zo bij de Engelstalige versie. Ik weet niet of dit een bug is die gerapporteerd moet worden en, zo ja, waar die gerapporteerd moet worden.

Comment 2

[Tim Maks van den Broek [:mad_maks]]

Bedankt voor je werk. het is handiger dat je een patch maakt van je wijzigingen (ik zal deze nu maken voor in  deze bug) zodat de andere vertalers niet door alle bestanden heen moeten om te kijken wat je verandert hebt. 

mail me even privé als je daarin uitleg wilt.

over het thema: dat is een bug (lijkt me) doe eens een zoekopdacht in  bugzilla en als je hem niet vind, maak zelf een nieuwe bug aan.

Comment 3

[Tim Maks van den Broek [:mad_maks]]

Attachment: nl-dick patch

Comment 4

[Tim Maks van den Broek [:mad_maks]]

Een eerste opmerking op de patch: acceskeys moeten in de zin waar het naar verwijst voorkomen dus "j" voor downloadmanager kan niet. Dit in tegenstelling tot commandkeys daar mag je wel een andere letter gebruiken.

verder laat ik het over aan niek wat hij van de voorgestelde veranderingen vind.

Comment 5

[u81239]

(In reply to comment #4)
> Dit in tegenstelling tot commandkeys daar mag je wel een andere letter gebruiken.

Sterker nog het is voor command keys afgeraden om deze te wijzigen t.o.v. het origineel.

Comment 6

[Ton [:Tonnes]]

(In reply to comment #1)
> Created an attachment (id=410803) [details]
> nl.jar met voorgestelde wijzigingen

Eigenlijk keur ik alleen de wijzigingen als -> mits en ‘Fout bij …’ goed, en uiteraard de typefouten. Van de rest kunnen we stellen dat het óf al is aangepast in de bestanden voor TB en nog niet in SM, of (zoals bij ‘junkmail’) als ik me niet vergis al eens was besproken in de bug van 1.1 en min of meer niet kon doorgaan om reden van consistentie.

Voor TB heb ik een patch met de genoemde wijzigingen gemaakt. De bestanden voor SM 2 met dezelfde wijzigingen heb ik bekeken en daarvoor zou ik wel een patch willen maken, zodat deze (vast) gelijk zijn met die van TB. Dit kost echter wat tijd, zeker omdat ik de gewoonte heb de bestanden volledig na te lopen en als het kan geen overige fouten achter te laten. De volledige bron van SM 2 moet echter nog in zijn geheel worden vergeleken met die van 1.1 en omdat dat nog niet is gebeurd (wat ik als ‘mijn schuld’ zou kunnen beschouwen), is het resultaat dat 2.0 er m.i. verre van optimaal uitziet. Als de druk van FF 3.6 af is zal ik me hiermee bezighouden, of als een ander hiermee al wil beginnen is dat ook prima.

Dick: misschien is het handig als je het taalpakket van 1.1x (en de meest actuele source voor TB) ter hand neemt voordat je wijzigingen voorstelt? Op die manier vermijden we mogelijk voorstellen voor aanpassingen die toch al moesten gebeuren of voor bestanden die nog niet zijn gesynchroniseerd. Uiteraard kan het, als je een patch gaat maken, geen kwaad de rest van het bestand dan ook meteen in orde te maken.

Wat command keys betreft: inderdaad lijkt het me niet de bedoeling die te wijzigen, volgens het beleid van Mozilla.

Comment 7

[DickB]

Aan de vertalers van Seamonkey, ter geruststelling.
Als "buitenstaander" heb ik bewondering voor jullie omvangrijke werk waar ik veel plezier aan heb bij het gebruik van SM. 
Ik had voor mijzelf nl.jar aangepast (wegens enkele spelfouten en iets meer vanwege tekst die bij mij in de lay-out ongelukkig uitpakt en zo) en ter informatie naar jullie gestuurd zonder de bedoeling dat jullie maar meteen alles naar mijn wensen zouden gaan zetten. Doordat van mijn bericht een patch werd gemaakt werd mogelijk een andere suggestie gewekt. Voortaan zal ik voorzichtig zijn met wijzigingsvoorstellen (tenzij er natuurlijk iets wezenlijks is). Wel zal ik bij updates voor jullie kijken of er gevolgen zijn die specifiek voor mac van belang zijn.

Comment 8

[u81239]

(In reply to comment #7)
> Ik had voor mijzelf nl.jar aangepast (wegens enkele spelfouten en iets meer
> vanwege tekst die bij mij in de lay-out ongelukkig uitpakt en zo) en ter
> informatie naar jullie gestuurd zonder de bedoeling dat jullie maar meteen
> alles naar mijn wensen zouden gaan zetten.

Zeer welkom, bedankt voor de bijdrage :). In het vervolg suggesties voor wijzigingen lekker blijven opsturen, ook niet nodig om ‘voorzichtig’ te zijn o.i.d., alle bijdragen worden gewaardeerd.

> Doordat van mijn bericht een patch
> werd gemaakt werd mogelijk een andere suggestie gewekt.

Niet erg hoor, een patch is juist wel handig om te zien wat er precies gewijzigd is en om te vergelijken. Alleen worden patches natuurlijk wel becommentarieerd en niet altijd volledig overgenomen.

> Wel zal ik bij updates voor jullie kijken of er gevolgen zijn
> die specifiek voor mac van belang zijn.

Geloof niet dat er onder de vaste vertalers Mac-gebruikers zijn, dus wat extra aandacht kan geen kwaad. Dus daarvoor dank!

~Laurens

Comment 9

[DickB]

Ik kwam nog wat kleinigheden tegen in enkele bestanden. Kijk maar of je er iets aan hebt. 

mailNavigatorOverlay.dtd:

-<!ENTITY contextSendThisPage.label       "Deze pagina verzendenSend This Page...">
+<!ENTITY contextSendThisPage.label       "Deze pagina verzenden...">

-<!ENTITY contextSendThisLink.label       "Deze koppeling verzendenSend This Link...">
+<!ENTITY contextSendThisLink.label       "Deze koppeling verzenden...">

----------------------

accountManager.dtd

-<!ENTITY setDefaultButton.label "Instellen als het standaard">
+<!ENTITY setDefaultButton.label "Instellen als standaard">

------------------------

messenger -> addressbook -> abMailListDialog.dtd
was onvertaald gebleven. Het gaat om enkele regels. Voor ListNickName weten jullie vast wel iets beters dan mijn "vertaling":

<!ENTITY mailListWindow.title           "Mailinglijst">
<!-- Labels -->
<!ENTITY addToAddressBook.label         "Toevoegen aan: ">
<!ENTITY ListName.label                 "Lijstnaam: ">
<!ENTITY ListNickName.label             "Toegevoegde naam voor de lijst: "> // [ Eng. List nick name ]
<!ENTITY ListDescription.label          "Beschrijving: ">
<!-- See bug 58485, when we implement drag and drop, add 'or drag addresses' back in -->
<!ENTITY AddressTitle.label             "Geef e-mailadressen om toe te voegen aan de mailinglijst">

Er moet misschien ook in dit bestand worden gekeken naar de Access Keys, maar ik weet niet welke afspraken daarover bestaan.

Comment 10

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #9)
> Ik kwam nog wat kleinigheden tegen in enkele bestanden. Kijk maar of je er iets
> aan hebt. 
> 
>

Niek, kijk jij hier even naar?

Comment 11

[Tim Maks van den Broek [:mad_maks]]

Bij het testen voor seamonkey 2.0.1 zag ik dat er nogal wat acceskeys niet kloppen/ dubbel zijn zoals in voorkeuren => vormgeving => inhoud

Niek zie jij kans om dit aantepakken voor 2.0.2? (of een andere vrijwilliger?)

Comment 12

[Tim Maks van den Broek [:mad_maks]]

Hoe staat het met deze bug, Niek ben jij nog van plan om je bezig te houden met seamonkey?

Comment 13

[niek]

Ik werk aan een patch voor de hierboven genoemde issues, met name de accesskeys en de voorkeurenvensters.

Comment 14

[Tim Maks van den Broek [:mad_maks]]

goed om te horen dat het je aandacht heeft :-)

Comment 15

[Ton [:Tonnes]]

Niek, neem je hierbij 1.18 als voorbeeld? Zoals je weet moeten de wijzigingen daaruit nog steeds worden verwerkt (ik zal er binnenkort naar kijken), dus qua access keys kan je dat al wat werk schelen.

Comment 16

[Tim Maks van den Broek [:mad_maks]]

http://www.frenchmozilla.fr/glossaire/nl/doublons.php

is een handige pagina om een vergelijk te maken tussen browser/seamonkey mail/seamonkey

Comment 17

[Ton [:Tonnes]]

Attachment: Correcties n.a.v. 1.1x/FF/TB, deel 1

‘Gelijktrekkingen’/correcties voor de map /suite, excl. de submappen /mailnews en /common.

Comment 18

[Tim Maks van den Broek [:mad_maks]]

Niek, ik wil graag de voorgestelde veranderingen toepassen, wil jij de patch bekijken aub.

Comment 19

[niek]

De patch bekeken en geen problemen aangetroffen. Bij het indienen van het comment kreeg ik de foutmelding: You are not authorized to edit attachment 435700 [details] [diff] [review]. Bij deze OK.

Comment 20

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 435700 [details] [diff] [review]
Correcties n.a.v. 1.1x/FF/TB, deel 1

toegepast op 1.9.1, 1.9.2 en central

Comment 21

[Tim Maks van den Broek [:mad_maks]]

http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/nl/rev/e8c8f57ee901

copyright.string bestaat nog wel in 1.9.1

Comment 22

[Ton [:Tonnes]]

Dit is een wijziging uit comm-central (http://hg.mozilla.org/comm-central/rev/8a5ef0bf1570), en ik vrees dat ik die (net als voor TB eerder) als bron voor de patch heb gebruikt. Weet niet of er meer van dergelijke verschillen zijn en terugdraaien mogelijk beter is, kun je dat even controleren?

Overigens, in http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/nl/rev/e8c8f57ee901 schrijven we altijd nog ‘Mozilla-project’. Zou je alsjeblieft ook wat meer op onjuist spatiegebruik willen letten (zie http://www.spatiegebruik.nl)? Ik schat dat dat zo’n 30% van de fouten veroorzaakt… ;)

Comment 23

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #22)
> Dit is een wijziging uit comm-central
> (http://hg.mozilla.org/comm-central/rev/8a5ef0bf1570), en ik vrees dat ik die
> (net als voor TB eerder) als bron voor de patch heb gebruikt. Weet niet of er
> meer van dergelijke verschillen zijn en terugdraaien mogelijk beter is, kun je
> dat even controleren?
> 

Er zijn niet meer verschillen in de patch zover ik zie, de dashboard meld dat alles nu goed is

> Overigens, in
> http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/nl/rev/e8c8f57ee901 schrijven
> we altijd nog ‘Mozilla-project’. Zou je alsjeblieft ook wat meer op onjuist
> spatiegebruik willen letten (zie http://www.spatiegebruik.nl)? Ik schat dat dat
> zo’n 30% van de fouten veroorzaakt… ;)

Ik heb alleen de patch teruggedraaid en niet op de inhoud gelet, dat laat ik aan jullie over ;0

maar ik zal het aanpassen

Comment 24

[Ton [:Tonnes]]

Attachment: Correcties n.a.v. 1.1x/FF/TB, deel 2

Toepassing van de recente patch (attachment 444333 [details] [diff] [review]) voor /mail/chrome/messenger en ‘gelijktrekkingen’/correcties voor de map /suite/chrome/mailnews, excl. de submap /pref.

Comment 25

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 446926 [details] [diff] [review]
Correcties n.a.v. 1.1x/FF/TB, deel 2

toegepast op 1.9.1 en central

Comment 26

[Ton [:Tonnes]]

Attachment: Map mailnews/pref

Idem voor de submap /suite/chrome/mailnews/pref + 3 andere inconsistenties.

Comment 27

[Ton [:Tonnes]]

Attachment: Map mailnews/pref v2

Bevat enkele correcties.

Comment 28

[Ton [:Tonnes]]

Attachment: Map mailnews/pref v3

Nog enkele correcties (sorry, maar het was min of meer nodig).

Comment 29

[Ton [:Tonnes]]

Attachment: Map common (root) + common/pref

Comment 30

[Tim Maks van den Broek [:mad_maks]]

http://clear.com.ua/misc/l10n-keys/nl.html 

een mooi overzicht van "foute" acceskeys in de nederlandse seamonkey

Comment 31

[Ton [:Tonnes]]

Na de patches nog maar eens kijken. ;) Eigenlijk maak ik me meer zorgen over gewijzigde command keys…

Comment 32

[Ton [:Tonnes]]

Attachment: Rest van /suite/chrome/common

De patch bevat de laatste correcties n.a.v. een vergelijking met de reeds nagelopen 1.1x, en verder waar nodig. Als het goed is zijn hiermee de (ergste) fouten er uit, maar een controle van access keys is wellicht nodig. Voor de bestanden voor het standaardprofiel volgt nog een aparte patch.

Niek, doe jij nog aan review? Of anders Tim-maks?

Comment 33

[niek]

Dag Ton, ik ben met de reviews bezig.

Comment 34

[Ton [:Tonnes]]

Attachment: Map common (root) + common/pref v2

Iets aangepast n.a.v. onverwerkte keys en 2 strings in consoleOverlay.dtd.

Comment 35

[Ton [:Tonnes]]

Attachment: Bestanden voor standaardprofiel

De toegezegde (laatste) patch.

Comment 36

[Tim Maks van den Broek [:mad_maks]]

Niek hoe staat het met je review, ik zou toch heel graag de verbeteringen willen gaan doorvoeren zodat het mee kan in de volgende update van seamonkey.

Comment 37

[niek]

Comment on attachment 435700 [details] [diff] [review]
Correcties n.a.v. 1.1x/FF/TB, deel 1

OK

Comment 38

[niek]

Comment on attachment 449528 [details] [diff] [review]
Map mailnews/pref v2

OK

Comment 39

[niek]

Comment on attachment 449552 [details] [diff] [review]
Map mailnews/pref v3

OK

Comment 40

[niek]

Comment on attachment 449553 [details] [diff] [review]
Map common (root) + common/pref

OK

Comment 41

[niek]

Comment on attachment 449429 [details] [diff] [review]
Map mailnews/pref

OK

Comment 42

[niek]

Comment on attachment 451901 [details] [diff] [review]
Map common (root) + common/pref v2

OK

Comment 43

[niek]

Comment on attachment 451907 [details] [diff] [review]
Bestanden voor standaardprofiel

OK

Comment 44

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #38)
> (From update of attachment 449528 [details] [diff] [review])
> OK

niek, waarom geef je een ok op attachments die ingetrokken zijn? :-)

en als het goed is kan jij de attachments bewerken en de review vlag op + zetten als je het goedkeurt en - als je het afkeurt

Comment 45

[niek]

weer wat geleerd! ik was bang iets over te slaan ;)

Comment 46

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 449552 [details] [diff] [review]
Map mailnews/pref v3

toegepast op 1.9.1 en central r=niek

Comment 47

[niek]

Comment on attachment 451907 [details] [diff] [review]
Bestanden voor standaardprofiel

ik heb een + gezet in de bovenste dropdown. ok?

Comment 48

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 451901 [details] [diff] [review]
Map common (root) + common/pref v2

toegepast op 1.9.1 en central

Comment 49

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #47)
> (From update of attachment 451907 [details] [diff] [review])
> ik heb een + gezet in de bovenste dropdown. ok?

perfect :-)

ps. als ik online ben, ben ik altijd te vinden in #mozilla.nl op irc.mozilla.org

Comment 50

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 451907 [details] [diff] [review]
Bestanden voor standaardprofiel

toegepast op 1.9.1 en central

Comment 51

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #45)
> weer wat geleerd! ik was bang iets over te slaan ;)

heb je er toch een overgeslagen.....https://bugzilla.mozilla.org/attachment.cgi?id=451687

Comment 52

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 451687 [details] [diff] [review]
Rest van /suite/chrome/common

toegepast op 1.9.1 en central

Comment 53

[Tim Maks van den Broek [:mad_maks]]

Ik stel voor om te gaan werken aan seamonkey 2.1 ( https://l10n-stage-sj.mozilla.org/shipping/dashboard?locale=nl&tree=sea21x ) die vooralsnog de bestanden in central (bug 457393 ) gebruikt.

Comment 54

[niek]

OK, gaan we daar verder.

Comment 55

[Ton [:Tonnes]]

Attachment: Nits voor SM2.0/1.9.1 (e.v.)

Het lijkt mij beter om de bug nog even open te houden totdat 2.1 er is.

Deze patch verzorgt enkele restpuntjes na de voorgaande patches voor SM 2.1 en bevat
- ‘vergeten’ key in geschiedenis
- niet-werkende key (W in mail)
- diverse dubbele access keys
- inconsistente benamingen
- aanpassing van standaard feednaam (er verschijnt nu ‘Blogs & nieuwsfeeds’)

Tim, kun je deze toepassen op 1.9.1, 1.9.2 en central? Dit omdat de aanpassingen op alle en voor een deel ook op TB 3.x (!) van toepassing zijn.

Comment 56

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #55)
> Het lijkt mij beter om de bug nog even open te houden totdat 2.1 er is.
>

hierbij

Comment 57

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 480441 [details] [diff] [review]
Nits voor SM2.0/1.9.1 (e.v.)

toegepast op 1.9.1 en central

Comment 58

[Ton [:Tonnes]]

Dank. Past-ie niet op 1.9.2?

Comment 59

[Tim Maks van den Broek [:mad_maks]]

er wordt geen seamonkey gemaakt van 1.9.2 :-)

en je veranderingen die ook voor tb gelden moet ik verwerken in een nieuwe patch

Comment 60

[Ton [:Tonnes]]

(In reply to comment #59)
> er wordt geen seamonkey gemaakt van 1.9.2 :-)
Dat weet ik :) maar zou het niet mooi zijn als identieke strings wanneer mogelijk meteen overal gecorrigeerd worden i.p.v. per bug of branch, los van of de branch dienst doet? Nu blijven sommige fouten ergens bestaan en dat kan weleens verwarrend werken (zoals hier, waar wijzigingen voor alledrie van belang zijn, en gedeeltelijk voor verschillende producten).
Maar goed, we hebben het er geloof ik al eens eerder over gehad en ik maak ze voor 1.9.2 wel apart. Voor TB welteverstaan, maar uit nieuwsgierigheid (en omdat hierdoor de vraag opnieuw rijst): wat was ook alweer het precieze bezwaar, de niet-bijpassende bug, of het feit dat een branch ergens niet voor wordt gebruikt? Let wel: naast de verwarring ben ik ook weleens bang dat ‘achtergelaten’ fouten later weer opduiken. Maar als je kunt garanderen dat importeeracties bij latere versies altijd succes hebben, dan is de angst wellicht ongegrond. :)

Comment 61

[Tim Maks van den Broek [:mad_maks]]

Volgens mij zei ik in comment #59 dat ik de verandering ook zou doorvoeren in de andere producten, dus een nieuwe patch (door jou) in de andere bug is niet nodig. In de 1.9.2 tree is het onzin om de suite te onderhouden er wordt en zal niks mee gedaan worden. En al zou je het willen welke veranderingen volg je dan, die van 1.9.1 of central...... 

1.9.2 kan wat suite betreft gewist worden / genegeerd worden en deze zal nooit kunnen dienen als uitgangspunt voor toekomstige versie's. Dat is altijd de laatste publieke versie (en die komt momenteel uit 1.9.1)

Comment 62

[Ton [:Tonnes]]

(In reply to comment #61)
> Volgens mij zei ik in comment #59 dat ik de verandering ook zou doorvoeren in
> de andere producten, dus een nieuwe patch (door jou) in de andere bug is niet
> nodig.

Volgens mij zei je daar dat je iets moest verwerken, maar niet dat je dat ook zou doen. Jou kennende en omdat dat als een bezwaar klonk ging ik ervan uit dat dat (nog) niet zo was en dat een patch welkom is. Op een dergelijke manier klagen lijkt me dus een beetje ongepast; ik zou blij zijn met een ontvangen patch voor iets dat op dit moment van belang is voor TB 3.1.x. :)

> In de 1.9.2 tree is het onzin om de suite te onderhouden er wordt en zal
> niks mee gedaan worden. En al zou je het willen welke veranderingen volg je
> dan, die van 1.9.1 of central...... 

Prima, heel goed zelfs, dan zou ik die inderdaad en zo snel mogelijk verwijderen. Was dat laatste een vraag? In dat geval: wat denk je zelf? :)

Terzijde: zou je (in vertalingen) willen oppassen met het gebruik van de woorden ‘verandering’ en ‘veranderen’? Dit heeft iets van een gedaantewisseling (m.a.w. iets verandert meestal uit zichzelf, zoals bv. de Hulk). Als het om wijzigingen in code of een programma (dus door een ander/gebruiker/en-US-tree) gaat, spreken we doorgaans over wijzigen en wijzigingen.

Comment 63

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #62)
 Op een dergelijke manier
> klagen lijkt me dus een beetje ongepast; ik zou blij zijn met een ontvangen
> patch voor iets dat op dit moment van belang is voor TB 3.1.x. :)

klagen???? volgens mij is hiersprake van miscommunicatie. ik ben heel blij met elke patch! maar vond het onzin om een patch die heel goed om te zetten is weer te vragen voor TB terwijl ik het makkelijk zelf kon doen. ik wilde je werk besparen.

Comment 64

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #62)

> Prima, heel goed zelfs, dan zou ik die inderdaad en zo snel mogelijk
> verwijderen. Was dat laatste een vraag? In dat geval: wat denk je zelf? :)
> 

ook hier was ik blijkbaar niet duidelijk. Ik bedoelde met de laatste zin: als je alle patches toch wilt doorvoeren op 1.9.2 welke pas je dan toe, 1.9.1 of central. of te wel onzin.....

Comment 65

[Tim Maks van den Broek [:mad_maks]]

de nieuwe compare-locale heeft nog wat "foutjes" ontdekt https://l10n-stage-sj.mozilla.org/dashboard/compare?run=99281

Comment 66

[Ton [:Tonnes]]

(In reply to comment #63)
> (In reply to comment #62)
> klagen???? volgens mij is hiersprake van miscommunicatie. ik ben heel blij met
> elke patch! maar vond het onzin om een patch die heel goed om te zetten is weer
> te vragen voor TB terwijl ik het makkelijk zelf kon doen. ik wilde je werk
> besparen.

Ha ja ok… ik jou dus ook, vandaar. :) Ik vatte het denk ik even verkeerd op, wat vast kwam doordat je zin begon met "Volgens mij zei ik", en zo’n uitspraak valt bij mij vaak een beetje eh… ;)

(In reply to comment #65)
> de nieuwe compare-locale heeft nog wat "foutjes" ontdekt
> https://l10n-stage-sj.mozilla.org/dashboard/compare?run=99281

Inderdaad, mooi script ook. Ben met een patch bezig en zag nog wat andere hieraan gerelateerde kleinigheden. Misschien is er ooit iets over het hoofd gezien met het kopiëren vanuit /mail… :-/

Comment 67

[Ton [:Tonnes]]

Attachment: Fix voor compare build 98637

Dit zou de boel moeten fixen.

Er viel iets op in ldapAutoCompErrs.properties van /suite, daar zijn 6 entity’s op de Thunderbird-in-Windows-manier vertaald (10021: Extra, Opties etc.) en bovendien gelijk aan die van hetzelfde bestand in /mail, dus die zouden voor SM niet juist zijn. In en-US zijn ze ook gelijk, maar hanteren ze juist de SM-begrippen. Ik heb aangenomen dat dit een foutje is (in en-US) en dat SM dit bestand in /suite gebruikt, en dit hier aangepast.

(In reply to comment #64)
> (In reply to comment #62)
> 
> ook hier was ik blijkbaar niet duidelijk. Ik bedoelde met de laatste zin: als
> je alle patches toch wilt doorvoeren op 1.9.2 welke pas je dan toe, 1.9.1 of
> central. of te wel onzin.....

Tja, ik denk altijd “waar mogelijk of van toepassing”, zodat er alleen specifieke verschillen tussen versies mogen bestaan (m.a.w. de laatste optimalisatie op alle toepassen), maar dat zal technisch misschien lastig zijn.

Comment 68

[niek]

Comment on attachment 483251 [details] [diff] [review]
Fix voor compare build 98637

Geen gekke dingen of fouten gevonden ;)

Comment 69

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 483251 [details] [diff] [review]
Fix voor compare build 98637

toegepast op 1.9.1 en central

Comment 70

[Ton [:Tonnes]]

Ik merkte zojuist dat versie 2.0.9 (uitgebracht rond 20-10 maar gedateerd 30-9) nog niet de bovenstaande wijzigingen bevat. Klopt dit (en gaat het de volgende keer wel vanzelf goed), of was/is er nog een nieuwe release-tag nodig?

Comment 71

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #70)
> Ik merkte zojuist dat versie 2.0.9 (uitgebracht rond 20-10 maar gedateerd 30-9)
> nog niet de bovenstaande wijzigingen bevat. Klopt dit (en gaat het de volgende
> keer wel vanzelf goed), of was/is er nog een nieuwe release-tag nodig?

dat kan kloppen, de sign of is gedaan om 2010-10-15 14:46 en is nog pending voor de volgende uitgave. de patch was dus net telaat voor versie 2.0.9 en gaat dus mee in 2.0.10

Comment 72

[Ton [:Tonnes]]

Attachment: Foutje in ster/markering e.a.

Herstelt de ster-/markeerfout zoals aangetroffen bij 2.1/central en enkele andere kleinigheden die ook in central nog niet juist zijn.

N.B. Graag net als hier in folderProps.dtd ook ‘bewaren’ gebruiken waar ‘behouden’ staat (3x) in de bug/patch voor 2.1/central (handmatig achteraf?).

Comment 73

[Tim Maks van den Broek [:mad_maks]]

(In reply to comment #72)
> Created attachment 487295 [details] [diff] [review]
> Foutje in ster/markering e.a.
> 
> Herstelt de ster-/markeerfout zoals aangetroffen bij 2.1/central en enkele
> andere kleinigheden die ook in central nog niet juist zijn.

In thunderbird hebben we indertijd gekozen voor deze vertaling, waarom is dat nu fout?

2006-07-29 :

http://bonsai-l10n.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=messenger.properties&branch=1.8.2.23&root=/l10n&subdir=l10n/nl/mail/chrome/messenger&command=DIFF_FRAMESET&rev1=1.8.2.22&rev2=1.8.2.23

Comment 74

[Ton [:Tonnes]]

Die wijziging (a.g.v. bug 345129) betrof destijds alleen Thunderbird en niet SeaMonkey. In het Engels wordt het onderscheid tussen Starred en Flagged in TB resp. SM nog steeds gemaakt, hoewel de entity’s gelijk zijn - http://mxr.mozilla.org/comm-central/search?string=notflagged&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-central .

In de huidige SeaMonkey viel me deze inconsistentie in de mailnews-bestanden op doordat er over markering wordt gesproken en er een kolom voor Markering bestaat (i.p.v. Met ster), wat inhoudt dat alle verwijzingen naar een ster onjuist zijn, dus ook in de sectie Accountinstellingen - Schijfruimte. Toegegeven, deze inconsistentie was er ook al in 1.1x (al is het daar haast onzichtbaar), maar ik denk dat er ooit wat te ijverig is gekopieerd.

Aanvankelijk wilde ik zeggen dat het me eigenlijk niet veel uitmaakt of we in SM het Engelse Flagged/Gemarkeerd willen volgen of dat we Starred/Met ster zoals bij TB willen hanteren, maar het feit blijft dat in SM een vlaggetjespictogram zichtbaar is en in TB dat van een ster, wat het gebruik van Ster naar mijn mening onmogelijk maakt. Markering (middels de markeringsvlag) lijkt me dus beter op zijn plaats. Misschien dus maar aanhouden, dit toch doorvoeren en wellicht voorstellen ook Starred in SM (en-US) te gebruiken?

Comment 75

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 487295 [details] [diff] [review]
Foutje in ster/markering e.a.

(In reply to comment #74)
> Die wijziging (a.g.v. bug 345129) betrof destijds alleen Thunderbird en niet
> SeaMonkey. In het Engels wordt het onderscheid tussen Starred en Flagged in TB
> resp. SM nog steeds gemaakt, hoewel de entity’s gelijk zijn -
> http://mxr.mozilla.org/comm-central/search?string=notflagged&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-central
> .
> 
> In de huidige SeaMonkey viel me deze inconsistentie in de mailnews-bestanden op
> doordat er over markering wordt gesproken en er een kolom voor Markering
> bestaat (i.p.v. Met ster), wat inhoudt dat alle verwijzingen naar een ster
> onjuist zijn, dus ook in de sectie Accountinstellingen - Schijfruimte.
> Toegegeven, deze inconsistentie was er ook al in 1.1x (al is het daar haast
> onzichtbaar), maar ik denk dat er ooit wat te ijverig is gekopieerd.
> 
> Aanvankelijk wilde ik zeggen dat het me eigenlijk niet veel uitmaakt of we in
> SM het Engelse Flagged/Gemarkeerd willen volgen of dat we Starred/Met ster
> zoals bij TB willen hanteren, maar het feit blijft dat in SM een
> vlaggetjespictogram zichtbaar is en in TB dat van een ster, wat het gebruik van
> Ster naar mijn mening onmogelijk maakt. Markering (middels de markeringsvlag)
> lijkt me dus beter op zijn plaats. Misschien dus maar aanhouden, dit toch
> doorvoeren en wellicht voorstellen ook Starred in SM (en-US) te gebruiken?

Wat mij betreft is de verandering met deze uitleg ok.

Comment 76

[niek]

Comment on attachment 487295 [details] [diff] [review]
Foutje in ster/markering e.a.

prima, met ster/gemarkeerd eveneens

Comment 77

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 487295 [details] [diff] [review]
Foutje in ster/markering e.a.

toegepast

Comment 78

[Ton [:Tonnes]]

Attachment: Nits in folderProps.dtd e.a.

…zoals onlangs aangetroffen in 2.1, evenals 2 nits in commentaarregels.

Comment 79

[niek]

Comment on attachment 492106 [details] [diff] [review]
Nits in folderProps.dtd e.a.

OK voor nu, t.z.t. in context te bezien. 
Prettige feestdagen.

Comment 80

[Ton [:Tonnes]]

Dank, insgelijks. Wacht je ook niet te lang meer met de andere? Overigens zijn de teksten lokaal te zien/testen, dus ik begrijp “t.z.t. in context” niet zo goed…

Comment 81

[Tim Maks van den Broek [:mad_maks]]

Comment on attachment 492106 [details] [diff] [review]
Nits in folderProps.dtd e.a.

toegepast, http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/nl/rev/d731467e4127

en natuurlijk de beste wensen voor het nieuwe jaar :-)