Developer forum

Hi Adrian,

If I understand your question correctly:

Have a root expression group and have it negated, making the "Equal" into "not Equal".
In the example below it would list all products not in LANG2.

BR
Snedker

Hi Morten,

Long time no speak :)

I was thinking more along the lines of documenting the product, not defining it in the language.
The product may be created in LANG2, but it does not mean that it was documented. I am looking for a way of separating documented products, and I was hoping that the generated properties may help me with that.

Any idea?

Thank you,
Adrian

Hi Adrian,

Indeed it is! :-) I'm still recovering from my last visit :-D

Okay, so...I'm trying to wrap my brains around what you mean by "documented". Is it more in the line of:

1. Define “documented” as a rule set per channel/language (e.g., required fields: Name, ShortDescription, LongDescription, Primary image, SEO Title, SEO Description, etc.).

2. Use PIM Completeness to calculate a % per product/language.

3. Filter: Language = LANG2 AND Completeness < 100% (or < your threshold, e.g. 80%). That (as I understand) would imply “products in LANG2 that are not fully documented.”

This approach is explicit, maintainable, and visible to editors; you can tweak the field set without rewriting queries.

Or am I still way off?

BR
Snedker

Well, yes. But works a little differently under the hood, than you're laying out.  Completeness is calculated on the fly, and will be based only on records inflicted by the query. So, if LanguageId is part of your query, the the completeness will based on that, and not products in other languages.

If ProductShortDescription is set on LANG1, but not on LANG2, you will have a higher completeness on LANG1.

/Snedker

I see. It makes sense.
What about the clarification for those 3 generated fields? How are they supposed to be used? What are they returning?

Thank you,
Adrian

Hi Adrian,

WHAT THE THREE GENERATED FIELDS ACTUALLY MEAN:

• Product is fully translated (boolean)
  True if the product has a language row for all languages in the index scope (typically the channel/shop languages you indexed). It does not look at field fill/quality - only existence of language records.

• Product translated to (multi-value list of LanguageIDs)
  The set of languages the product has a language row for. Example: ["LANG1","LANG3"]. Useful for “contains/does not contain” checks.

• Product translation count (integer)
  How many language rows exist for the product inside the index scope. Example: 2.

And scope matters: these are computed against whatever languages the index/channel includes. If your index only contains LANG1 and LANG2, then “fully translated” means “has both LANG1 and LANG2”.

HOW TO USE

• Products not localized to LANG2 (pure translation presence, not documentation):

  • Product translated to does not contain LANG2
    (Equivalent: Product translation count < <expected total> when the scope is fixed, but the “does not contain” check is clearer.)

• Products missing any language (i.e., not fully translated):

  • Product is fully translated = false

• Products translated to fewer than N languages:

  • Product translation count < N

How to combine with Completeness (per language)

• “Not documented in LANG2” (i.e., has a LANG2 row but missing required content):
  Language = LANG2 AND Completeness < 100%
  (Completeness is calculated on the fly for the current record set; the Language = LANG2 filter scopes it correctly.)

• “Either not translated to LANG2 at all, or translated but under-documented”:
  (Product translated to does not contain LANG2)
  OR
  (Language = LANG2 AND Completeness < 100%)

This last one is usually what people want operationally.

WHAT TO WATCH OUT FOR

• If a product has no LANG2 row, then Language = LANG2 won’t match it, so you must include the “does not contain LANG2” branch to catch it.

• Variants: decide whether you evaluate completeness on parent, variant, or both - indexes can be set to index either/both. Keep the logic consistent with that choice.

• Fallbacks: those generated fields ignore any UI fallback behavior; they only reflect real language rows present in the DB/index.

I hope the above covers your question, otherwise let me know.

BR
Snedker

Hi Morten,

Thank you very much for this detailed description.

It is very useful.

Thank you,
Adrian

Added to documentation: https://doc.dynamicweb.dev/documentation/implementing/repositories/indexes/productindexes.html#auto-generated-fields

/Snedker