I think you would say I use soft g, as I'm Flemish we have a tendency to use soft all the time, but I cannot hear the difference between /ɡ/ and /dʒ/ in your examples using google translate to hear them didn't help much.
Oh and I pronounce it as "are you certain using this is not a mistake?" as when I need to discuss them people are often ... misguided ;).
As I understand IPA, it's supposed to be 'standard' in the sense that it describes sounds by the physical method of making them with human vocal apparatus, rather than by reference to any particular language or dialect. That doesn't stop any given sound still being potentially confusing to speakers of a language that it doesn't fit naturally into!
Listening to the sound samples at those links, they seem fine to me – both pairs are clearly distinguishing what I'd think of as the 'soft' and 'hard' sounds made by 'g' in English. (It sounds as if the two for /dʒ/ are actually the same sample.) I agree that the /ɡ/ sample on the Dutch page is a bit clearer in audio quality than the one on the English page, but the latter still seemed clear enough to me.
Oh and I pronounce it as "are you certain using this is not a mistake?" as when I need to discuss them people are often ... misguided ;).
I'm interested to know what you mean by that. Is this an engineering complaint that people use regular expressions when another tool would be better for the job, or a theoretical complaint that people often say 'regular expression' to describe something that doesn't satisfy the technical definition of a regular expression at all (e.g. Perl supporting back-references), or something else entirely?
At my work we often have to extract data from outputs our customer send us. More or less mutilated.
People often try to use regular expressions to parse this output which actually has a grammar. Instead of using a parsing tool to understand the grammar they write 'quick' regexp patterns which gets the data they are interested in.
Then they discover that another version give the data in a slightly different way. Another platform again slightly different. In the end the 'simple' regexp becomes a tangled mess of linenoise. For bonus points this pattern often has to ignore line endings and will be unbound, then applied on multi-megabyte files, in a loop.
Going for the simpler parser would have been much easier in the long run. Or at least a sane middle way like textfsm.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Oh and I pronounce it as "are you certain using this is not a mistake?" as when I need to discuss them people are often ... misguided ;).
The sound samples at https://nl.wikipedia.org/wiki/Stemhebbende_postalveolaire_affricaat and https://nl.wikipedia.org/wiki/Stemhebbende_velaire_plosief were helpful, but strangely enough the samples at https://en.wikipedia.org/wiki/Voiced_palato-alveolar_affricate and https://en.wikipedia.org/wiki/Voiced_velar_stop were confusing.
I thought that IPA should be a sort of standard, so how come I needed to use the Dutch version? Interesting but confusing...
Listening to the sound samples at those links, they seem fine to me – both pairs are clearly distinguishing what I'd think of as the 'soft' and 'hard' sounds made by 'g' in English. (It sounds as if the two for /dʒ/ are actually the same sample.) I agree that the /ɡ/ sample on the Dutch page is a bit clearer in audio quality than the one on the English page, but the latter still seemed clear enough to me.
Oh and I pronounce it as "are you certain using this is not a mistake?" as when I need to discuss them people are often ... misguided ;).
I'm interested to know what you mean by that. Is this an engineering complaint that people use regular expressions when another tool would be better for the job, or a theoretical complaint that people often say 'regular expression' to describe something that doesn't satisfy the technical definition of a regular expression at all (e.g. Perl supporting back-references), or something else entirely?
People often try to use regular expressions to parse this output which actually has a grammar. Instead of using a parsing tool to understand the grammar they write 'quick' regexp patterns which gets the data they are interested in.
Then they discover that another version give the data in a slightly different way. Another platform again slightly different. In the end the 'simple' regexp becomes a tangled mess of linenoise. For bonus points this pattern often has to ignore line endings and will be unbound, then applied on multi-megabyte files, in a loop.
Going for the simpler parser would have been much easier in the long run. Or at least a sane middle way like textfsm.