From rsto at fastmailteam.com Wed Dec 1 04:16:43 2021 From: rsto at fastmailteam.com (Robert Stepanek) Date: Wed, 01 Dec 2021 11:16:43 +0100 Subject: Person Name: Gender-specific formatting Message-ID: Hi, I am co-authoring an IETF standards draft to represent contacts and addressbook data (draft-ietf-jmap-jscontact ). It aims to provide a backward-compatible alternative to the widely used VCARD contacts data format (RFC 6350 ). I see that Unicode PRI 434 has an open issue with regards to gender-specific formatting, and I would appreciate if we could share our findings in that area. One unresolved issue in our RFC draft is how to indicate the grammatical gender to use when addressing a name. This may be required to choose a honorific such as "Mr." or "Mrs." (in case the name object does not explicitly state them). Also, in some languages a grammatical gender is required for salutations (e.g. "Liebe Anna" vs. "Lieber Robert" in German). The VCARD standard defined a GENDER property to indicate the biological sex of a contact (and also a free-text value for gender). Some applications used this biological sex attribute to store and determine the grammatical gender of a contact. This is problematic because the biological sex and grammatical gender may not be equal. Also, the enumeration of allowed biological sex values seems poorly chosen, both in grammatical and biological contexts (e.g. "none", "other"). I wonder if a "grammaticalGender" field on a name might make sense? It looks to me as if "male", "female", "neuter" would cover a large number of languages, but I also understand that some allow for more genders (e.g. according to this Wikipedia entry the Zande language has four genders: male human, female human, animal and inanimate). Probably a free text-value in combination with a few predefined values for common genders could do the trick. That being said, I am not educated in linguistics. Could you please share your thoughts on gender-specific formatting in PRI434? At best, we could come to a solution that fits both standard works. Thanks! Robert P.S. in CC are my co-author as well as the IETF working group chair for the JSContact standard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehoogerbeets at gmail.com Wed Dec 1 13:19:19 2021 From: ehoogerbeets at gmail.com (Edwin Hoogerbeets) Date: Wed, 1 Dec 2021 11:19:19 -0800 Subject: Japanese plurals Message-ID: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Hi there, Our Japanese translators are asking me how to translate the following string resource: {folderCount, plural, one {Remove yourself from this shared folder.} other {Remove yourself from these shared folders.}} Our translation management system only allows for the "other" case in Japanese because it follows the CLDR rules as documented in common/supplemental/plurals.xml. The difficult thing is that the two English strings should be translated differently. Counters may not have plurals in Japanese, but demonstratives like "this", "these", "that" and "those" do. What the translators would like is to do a translation like this: {folderCount, plural, one {*??*?????????????????} other {*????*?????????????????}} (Bold added by me to highlight the translations of "this" and "these".) Is there any way we can revisit the plural categories for Japanese for cases like this? ie. add the "one" category for Japanese specifically for strings with demonstrative words in them? Thanks, Edwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.icu at gmail.com Wed Dec 1 17:22:22 2021 From: markus.icu at gmail.com (Markus Scherer) Date: Wed, 1 Dec 2021 15:22:22 -0800 Subject: Japanese plurals In-Reply-To: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> References: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Message-ID: On Wed, Dec 1, 2021 at 11:22 AM Edwin Hoogerbeets via CLDR-Users < cldr-users at corp.unicode.org> wrote: > Our Japanese translators are asking me how to translate the following > string resource: > > {folderCount, plural, one {Remove yourself from this shared folder.} other > {Remove yourself from these shared folders.}} > > Our translation management system only allows for the "other" case in > Japanese because it follows the CLDR rules as documented in > common/supplemental/plurals.xml. The difficult thing is that the two > English strings should be translated differently. Counters may not have > plurals in Japanese, but demonstratives like "this", "these", "that" and > "those" do. > > What the translators would like is to do a translation like this: > > {folderCount, plural, one {*??*?????????????????} other {*????* > ?????????????????}} > > (Bold added by me to highlight the translations of "this" and "these".) > There is a better way to do this. The "one" case triggers for different sets of numbers depending on the language, and usually not just for exactly one item. Even if you changed the plural rules for Japanese, the message would not make sense for, say, Russian, where "one" is used for 1, 21, 31, 41, ... What you want is an "exactly numerically 1" case, and if you are using ICU MessageFormat, you can do that with {folderCount, plural, *=1* {Remove yourself from this shared folder.} other {Remove yourself from these shared folders.}} Best regards, markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at macchiato.com Wed Dec 1 17:36:09 2021 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Wed, 1 Dec 2021 15:36:09 -0800 Subject: Japanese plurals In-Reply-To: References: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Message-ID: The CLDR plural rules are intended for any instance where the change in a number requires a change in a message; in some languages changes are required in verbs, or in references. So it appears that this is an example of where Japanese rules may require changes. The suggestion that Markus is recommending is a good workaround for the issue that you have, but we should consider whether to change the plural rules. So could you please file your request as a CLDR ticket, at https://cldr.unicode.org/index/bug-reports#h.o5tktlfjc4iw ? Mark On Wed, Dec 1, 2021 at 3:23 PM Markus Scherer via CLDR-Users < cldr-users at corp.unicode.org> wrote: > On Wed, Dec 1, 2021 at 11:22 AM Edwin Hoogerbeets via CLDR-Users < > cldr-users at corp.unicode.org> wrote: > >> Our Japanese translators are asking me how to translate the following >> string resource: >> >> {folderCount, plural, one {Remove yourself from this shared folder.} >> other {Remove yourself from these shared folders.}} >> >> Our translation management system only allows for the "other" case in >> Japanese because it follows the CLDR rules as documented in >> common/supplemental/plurals.xml. The difficult thing is that the two >> English strings should be translated differently. Counters may not have >> plurals in Japanese, but demonstratives like "this", "these", "that" and >> "those" do. >> >> What the translators would like is to do a translation like this: >> >> {folderCount, plural, one {*??*?????????????????} other {*????* >> ?????????????????}} >> >> (Bold added by me to highlight the translations of "this" and "these".) >> > There is a better way to do this. > The "one" case triggers for different sets of numbers depending on the > language, and usually not just for exactly one item. Even if you changed > the plural rules for Japanese, the message would not make sense for, say, > Russian, where "one" is used for 1, 21, 31, 41, ... > > What you want is an "exactly numerically 1" case, and if you are using ICU > MessageFormat, you can do that with > > {folderCount, plural, *=1* {Remove yourself from this shared folder.} > other {Remove yourself from these shared folders.}} > > > Best regards, > markus > _______________________________________________ > CLDR-Users mailing list > CLDR-Users at corp.unicode.org > https://corp.unicode.org/mailman/listinfo/cldr-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.icu at gmail.com Wed Dec 1 17:41:31 2021 From: markus.icu at gmail.com (Markus Scherer) Date: Wed, 1 Dec 2021 15:41:31 -0800 Subject: Japanese plurals In-Reply-To: References: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Message-ID: On Wed, Dec 1, 2021 at 3:36 PM Mark Davis ?? wrote: > The CLDR plural rules are intended for any instance where the change in a > number requires a change in a message; in some languages changes are > required in verbs, or in references. So it appears that this is an example > of where Japanese rules may require changes. > > The suggestion that Markus is recommending is a good workaround for the > issue that you have, but we should consider whether to change the plural > rules. > I would think that in most languages there is some special wording for exactly-number-1, like in both the English and Japanese examples in this thread. What you are suggesting amounts to making sure that the plural rules for every language have a plural keyword for that. I would rather we keep recommending =1. markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at macchiato.com Wed Dec 1 17:48:41 2021 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Wed, 1 Dec 2021 15:48:41 -0800 Subject: Japanese plurals In-Reply-To: References: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Message-ID: That's not our principle for the plural categories. In many languages the contents of 'one' are already exactly 1. If the language really *requires* a different message for "abc {0} def" when {0} is "1" vs when {0} is "2", then we need two plural categories where one of them contains 1 (at least) and the other contains 2 (at least). Mark On Wed, Dec 1, 2021 at 3:41 PM Markus Scherer wrote: > On Wed, Dec 1, 2021 at 3:36 PM Mark Davis ?? wrote: > >> The CLDR plural rules are intended for any instance where the change in a >> number requires a change in a message; in some languages changes are >> required in verbs, or in references. So it appears that this is an example >> of where Japanese rules may require changes. >> >> The suggestion that Markus is recommending is a good workaround for the >> issue that you have, but we should consider whether to change the plural >> rules. >> > > I would think that in most languages there is some special wording for > exactly-number-1, like in both the English and Japanese examples in this > thread. > What you are suggesting amounts to making sure that the plural rules for > every language have a plural keyword for that. > I would rather we keep recommending =1. > > markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ehoogerbeets at gmail.com Wed Dec 1 17:49:44 2021 From: ehoogerbeets at gmail.com (Edwin Hoogerbeets) Date: Wed, 1 Dec 2021 15:49:44 -0800 Subject: Japanese plurals In-Reply-To: References: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Message-ID: Actually, I meant for Japanese specifically. I was not suggesting to modify the rules for any other languages. The plural rules in common/supplemental/plurals.xml state that Japanese belongs to a group of languages that only supports the "other" category. Based on the example, I thought maybe we should consider moving it to the group of languages (along with English!) where it supports both the "one" and the "other" categories where "one" means "exactly 1" and "other" is everything else. For most Japanese phrases, there would be no difference between the "one" and "other" string, but for strings with demonstratives in them, there could be. Mark, I will file a jira and the committee can consider it. Thanks! Edwin On 12/1/21 3:41 PM, Markus Scherer wrote: > On Wed, Dec 1, 2021 at 3:36 PM Mark Davis ?? > wrote: > > The CLDR plural rules are intended for any instance where the > change in a number requires a change in a message; in some > languages changes are required in verbs,?or in references. So it > appears that this is an example of where Japanese rules may > require changes. > > The suggestion that Markus is recommending is a good workaround > for the issue that you have, but we should consider whether to > change the plural rules. > > > I would think that in most languages there is some special wording for > exactly-number-1, like in both the English and Japanese examples in > this thread. > What you are suggesting amounts to making sure that the plural rules > for every language have a plural keyword for that. > I would rather we keep recommending =1. > > markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at macchiato.com Wed Dec 1 17:52:14 2021 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Wed, 1 Dec 2021 15:52:14 -0800 Subject: Japanese plurals In-Reply-To: References: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Message-ID: Thanks, Mark On Wed, Dec 1, 2021 at 3:49 PM Edwin Hoogerbeets wrote: > Actually, I meant for Japanese specifically. I was not suggesting to > modify the rules for any other languages. > > The plural rules in common/supplemental/plurals.xml state that Japanese > belongs to a group of languages that only supports the "other" category. > Based on the example, I thought maybe we should consider moving it to the > group of languages (along with English!) where it supports both the "one" > and the "other" categories where "one" means "exactly 1" and "other" is > everything else. For most Japanese phrases, there would be no difference > between the "one" and "other" string, but for strings with demonstratives > in them, there could be. > > Mark, I will file a jira and the committee can consider it. > > Thanks! > > Edwin > > On 12/1/21 3:41 PM, Markus Scherer wrote: > > On Wed, Dec 1, 2021 at 3:36 PM Mark Davis ?? wrote: > >> The CLDR plural rules are intended for any instance where the change in a >> number requires a change in a message; in some languages changes are >> required in verbs, or in references. So it appears that this is an example >> of where Japanese rules may require changes. >> >> The suggestion that Markus is recommending is a good workaround for the >> issue that you have, but we should consider whether to change the plural >> rules. >> > > I would think that in most languages there is some special wording for > exactly-number-1, like in both the English and Japanese examples in this > thread. > What you are suggesting amounts to making sure that the plural rules for > every language have a plural keyword for that. > I would rather we keep recommending =1. > > markus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yacob at geez.org Wed Dec 1 17:53:44 2021 From: yacob at geez.org (Daniel Yacob) Date: Wed, 1 Dec 2021 18:53:44 -0500 Subject: Looking for Filter Syntax to Include a Transform Variant Attribute Message-ID: Greetings All, I'm seeking some help with the syntax for a transform filter identifier that includes a variant. Given the regular ?source? and ?target? attributes in an LDML transform file, a filter rule would take the form: :: source-target ; For a transform that also has a ?variant? attribute defined, how is the variant identifier expressed in the filter? I?ve tried a few forms like :: source-target-variant ; :: source-target_variant ; :: source-target/variant ; but they have all been rejected by the TestTransforms unit tests with ?Illegal ID? exceptions. Apologies if I?m overlooking this in the documentation. If this is indeed a gap, Section 10.3.8 of the TR35 on "Filter Rules" would benefit from a variant example. thanks! -Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.icu at gmail.com Wed Dec 1 18:00:49 2021 From: markus.icu at gmail.com (Markus Scherer) Date: Wed, 1 Dec 2021 16:00:49 -0800 Subject: Japanese plurals In-Reply-To: References: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Message-ID: On Wed, Dec 1, 2021 at 3:48 PM Mark Davis ?? wrote: > That's not our principle for the plural categories. In many languages the > contents of 'one' are already exactly 1. > > If the language really *requires* a different message for "abc {0} def" > when {0} is "1" vs when {0} is "2", then we need two plural categories > where one of them contains 1 (at least) and the other contains 2 (at least). > Except that we have the =1 mechanism for this specific case. My point is, surely Chinese and French and lots of other languages have words and phrases specific to an exact singular, but I don't think we want to split plural keyword "one" for every language to turn it into a keyword equivalent of =1. markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at macchiato.com Wed Dec 1 18:55:50 2021 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Wed, 1 Dec 2021 16:55:50 -0800 Subject: Japanese plurals In-Reply-To: References: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Message-ID: Mark On Wed, Dec 1, 2021 at 4:01 PM Markus Scherer wrote: > On Wed, Dec 1, 2021 at 3:48 PM Mark Davis ?? wrote: > >> That's not our principle for the plural categories. In many languages the >> contents of 'one' are already exactly 1. >> >> If the language really *requires* a different message for "abc {0} def" >> when {0} is "1" vs when {0} is "2", then we need two plural categories >> where one of them contains 1 (at least) and the other contains 2 (at least). >> > > Except that we have the =1 mechanism for this specific case. > > My point is, surely Chinese and French and lots of other languages have > words and phrases specific to an exact singular, but I don't think we want > to split plural keyword "one" for every language to turn it into a keyword > equivalent of =1. > > markus > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at macchiato.com Wed Dec 1 19:04:24 2021 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Wed, 1 Dec 2021 17:04:24 -0800 Subject: Japanese plurals In-Reply-To: References: <7ec368b0-d506-7a9b-ab6f-f071d2afc1a2@gmail.com> Message-ID: Nobody is proposing that. If the language *doesn't* *require* a different message for "abc {0} def" when {0} is "1" vs when {0} is "2" (for example), then we would not distinguish 'one' from 'other'. Note that this need not result in an increase in CLDR data; one thing that we've done with the grammar data is to add scope parameters, so that we can limit the data we collect to what is needed. So I'd already been thinking about applying that to plural rules. That way, for example, if currencies are invariant in the language (wrt plural categories) as they are in Japanese, we set the scope to exclude anything but 'other' from data gathering. Mark On Wed, Dec 1, 2021 at 4:01 PM Markus Scherer wrote: > On Wed, Dec 1, 2021 at 3:48 PM Mark Davis ?? wrote: > >> That's not our principle for the plural categories. In many languages the >> contents of 'one' are already exactly 1. >> >> If the language really *requires* a different message for "abc {0} def" >> when {0} is "1" vs when {0} is "2", then we need two plural categories >> where one of them contains 1 (at least) and the other contains 2 (at least). >> > > Except that we have the =1 mechanism for this specific case. > > My point is, surely Chinese and French and lots of other languages have > words and phrases specific to an exact singular, but I don't think we want > to split plural keyword "one" for every language to turn it into a keyword > equivalent of =1. > > markus > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mimckenna at paypal.com Thu Dec 9 13:01:50 2021 From: mimckenna at paypal.com (Mike McKenna) Date: Thu, 9 Dec 2021 19:01:50 +0000 Subject: Person Name: Gender-specific formatting In-Reply-To: References: Message-ID: Hi Robert, (I haven?t seen a response to this thread yet) In the proposed PersonName spec, we have left gender out of the name formatting, as the spec is specific to the name only, and not the grammatical context of the surrounding text. The current spec expects the calling application to know, and provide the correctly formatted honorifics or gender-specific connector terms, such as ?Farrah bint Ibrahim? vs ?Mohammed bin Ibrahim?. There is currently no accommodation for standard honorifics lists such as ?Mr, Ms, Mrs, Mx, Dr?, etc. But gender as part of a person object that happens to also contain the personName, and possibly variations of the personName (also-known-as, preferred-name, legal-name, birth-name, etc.) makes perfect sense. What I have found on ?standards? for gender enumeration are as follows: * ISO 20022 ? Financial Industry ? only has male, female * ISO 5218: not known, male, female, not applicable * UK Deed Poll: male, female, neither male nor female. NHS appears to be using the ISO 5218 codes * vCard4: male, female, other, nor or not applicable, unknown One thing to consider is that in the evolution of ?diversity and inclusion? as part of user interface and data design, we now have the preferred pronoun as part of the expected de facto person descriptor (WorkDay link; example English implementation details.). This can affect the surrounding grammar as well. Pronouns can add plural grammar with ?they/them? and indeterminate gender with new terms such as ?ze/hir?. Good discussion at IBM. Taking a look at the descriptors that go into person data in WorkDay is insightful wrt names, gender, pronouns, etc. Cheers, Mike McKenna [A close up of a sign Description automatically generated] PayPal World-Ready Engineering From: CLDR-Users on behalf of Robert Stepanek via CLDR-Users Date: Wednesday, December 1, 2021 at 9:01 AM To: cldr-users at corp.unicode.org Cc: Mario Loffredo , Bron Gondwana Subject: Person Name: Gender-specific formatting This message has links and attachments, please check both carefully before opening. Hi, I am co-authoring an IETF standards draft to represent contacts and addressbook data (draft-ietf-jmap-jscontact). It aims to provide a backward-compatible alternative to the widely used VCARD contacts data format (RFC 6350). I see that Unicode PRI 434 has an open issue with regards to gender-specific formatting, and I would appreciate if we could share our findings in that area. One unresolved issue in our RFC draft is how to indicate the grammatical gender to use when addressing a name. This may be required to choose a honorific such as "Mr." or "Mrs." (in case the name object does not explicitly state them). Also, in some languages a grammatical gender is required for salutations (e.g. "Liebe Anna" vs. "Lieber Robert" in German). The VCARD standard defined a GENDER property to indicate the biological sex of a contact (and also a free-text value for gender). Some applications used this biological sex attribute to store and determine the grammatical gender of a contact. This is problematic because the biological sex and grammatical gender may not be equal. Also, the enumeration of allowed biological sex values seems poorly chosen, both in grammatical and biological contexts (e.g. "none", "other"). I wonder if a "grammaticalGender" field on a name might make sense? It looks to me as if "male", "female", "neuter" would cover a large number of languages, but I also understand that some allow for more genders (e.g. according to this Wikipedia entry the Zande language has four genders: male human, female human, animal and inanimate). Probably a free text-value in combination with a few predefined values for common genders could do the trick. That being said, I am not educated in linguistics. Could you please share your thoughts on gender-specific formatting in PRI434? At best, we could come to a solution that fits both standard works. Thanks! Robert P.S. in CC are my co-author as well as the IETF working group chair for the JSContact standard. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 16868 bytes Desc: image001.jpg URL: From rsto at fastmailteam.com Tue Dec 14 03:15:00 2021 From: rsto at fastmailteam.com (Robert Stepanek) Date: Tue, 14 Dec 2021 10:15:00 +0100 Subject: Person Name: Gender-specific formatting In-Reply-To: References: Message-ID: Hi Mike, Thanks for your message. On Thu, Dec 9, 2021, at 8:01 PM, Mike McKenna wrote: > In the proposed PersonName spec, we have left gender out of the name formatting, as the spec is specific to the name only, and not the grammatical context of the surrounding text. The current spec expects the calling application to know, and provide the correctly formatted honorifics or gender-specific connector terms [...] I assume that this is unlikely to change when the spec becomes a standard? The currently published draft of PRI434 states gender-specific formatting to be an open issue (page 14). I would like to avoid coming up with a solution in our spec that then contradicts what gets defined in PRI434. > > But gender as part of a person object that happens to also contain the personName, and possibly variations of the personName (also-known-as, preferred-name, legal-name, birth-name, etc.) makes perfect sense. > > What I have found on ?standards? for gender enumeration are as follows: > * ISO 20022 ? Financial Industry ? only has male, female > * ISO 5218 : not known, male, female, not applicable > * UK Deed Poll : male, female, neither male nor female. NHS appears to be using the ISO 5218 codes > * vCard4 : male, female, other, nor or not applicable, unknown > Thanks, I was not aware of ISO 5128. I like the term "human sexes" which narrows down its purpose better than "gender" or "biological sex", the latter being a likely source of confusion as outlined in this article . > One thing to consider is that in the evolution of ?diversity and inclusion? as part of user interface and data design, we now have the *preferred pronoun* as part of the expected de facto person descriptor I also think about adding pronouns to our proposed contacts spec. I see that the Google Contacts API allows for pronouns in the free-text valued addressMeAs property of a Person object. Do you plan to use a structured or free-text value? Cheers, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From lwelti at yahoo.com Tue Dec 21 10:59:51 2021 From: lwelti at yahoo.com (Lucas Welti) Date: Tue, 21 Dec 2021 16:59:51 +0000 (UTC) Subject: Haitian Creole language "ht" References: <361229443.226490.1640105991576.ref@mail.yahoo.com> Message-ID: <361229443.226490.1640105991576@mail.yahoo.com> Hello, I noticed that "ht" CLDR Data is missing, and based in ?some [1]CLDR Tickets seems that is in the process to be added, by any chance do you have a timeline? [1] =?https://unicode-org.atlassian.net/browse/CLDR-14955 thanks in advance. regards,Lucas -------------- next part -------------- An HTML attachment was scrubbed... URL: From yacob at geez.org Fri Dec 31 10:57:48 2021 From: yacob at geez.org (Daniel Yacob) Date: Fri, 31 Dec 2021 11:57:48 -0500 Subject: Restricting Transform Filters to Run in Single Pass? Message-ID: Greetings, I've noticed a different behavior in a simple transform when it runs in isolation vs when it runs as a filter from *another* transform. To investigate, I removed all rules from the 2nd transform until *only* the filter remained. What I see in filter mode is that the output from the filter appears to be reevaluated until no further changes occur. To illustrate, my simple filter would have rules like: ABC > abc ; abc > xyz ; Then the difference in output appears like: *As a Stand-Alone Transform:* IN: ABC OUT: abc *As a Filter: * IN: ABC OUT: xyz But it's not always consistent, sometimes the "as a filter" case will produce the identical output as the stand-alone case. There seems to be a sensitivity to the number of test cases in my input file, but again not always. Is there rule syntax available that could restrict the filter to being evaluated only once? I can file a bug report if the behavior is unexpected. thanks! -Daniel PS: Maybe, maybe not related, in the same sessions I might see warnings like the following which have something to do with caching and Apache Derby. Dec 31, 2021 11:22:34 AM org.unicode.cldr.rdf.AbstractCache load WARNING: Could not read files in /var/folders/db/dbp4pwdd60z477q4y4pv8thc0000gn/T/1640967754872-0 Dec 31, 2021 11:22:34 AM org.unicode.cldr.rdf.AbstractCache load WARNING: Could not read files in /var/folders/db/dbp4pwdd60z477q4y4pv8thc0000gn/T/1640967754872-0 Dec 31, 2021 11:22:34 AM org.unicode.cldr.rdf.AbstractCache store INFO: # AbstractCache wrote to /var/folders/db/dbp4pwdd60z477q4y4pv8thc0000gn/T/1640967754872-0 org.unicode.cldr.unittest.web.testArgs=-n -q org.unicode.cldr.unittest.web.jdbcurl= Dec 31, 2021 8:22:51 AM org.unicode.cldr.web.DBUtils makeInstanceFrom WARNING: DBUtils: Note: changing the DBUtils singleton instance to org.apache.derby.jdbc.EmbeddedDataSource at 721eb7df @ null Dec 31, 2021 8:22:51 AM org.unicode.cldr.web.DBUtils setupSqlForServerType INFO: setting up SQL for database type Apache Derby v10.10.1.1 - (1458268) Dec 31, 2021 8:22:51 AM org.unicode.cldr.web.DBUtils setupSqlForServerType INFO: Note: Derby (embedded) mode. ** some features may not work as expected ** -------------- next part -------------- An HTML attachment was scrubbed... URL: