Specify JSON-LD fields to be translated

[S4mmyb]

We need to collect all metadata fields from our JSON-LD columns that should be translated (metadata_graph.metadata and project.metadata).

We can look those up from our legacy repo GitHub - regen-network/regen-registry-standards: 🌱 RDF and SHACL schemas for Regen Registry for existing metadata and from regen-data-standards repo for terrasos related fields once refactor Terrasos specific project schema to its own linkml class by clevinson · Pull Request #23 · regen-network/regen-data-standards and Add conservationStatus field to project metadata by wgardiner · Pull Request #20 · regen-network/regen-data-standards are merged.

[S4mmyb]

Hey folks, I went through and scraped info from all of the registered credit classes, projects, and batches to generate a list of key-value pairs for us to translate. cc @flagrede @blushi @wgardiner

Field	Translate Key	Translate Value
schema:description	Yes	Yes
schema:name	Yes	Yes
biomeType	Yes	Yes
bioregion	Yes	Yes
conservationStatus	Yes	Yes
ecologicalConnectivityIndex	Yes	No
ecosystemType	Yes	Yes
environmentType	Yes	Yes
environmentalAuthority	Yes	Yes
managementAreas	Yes	Yes
projectDeveloper	Yes	No (organization name)
projectDuration	Yes	No
projectMonitor	Yes	No (organization name)
projectOperator	Yes	No (organization name)
projectOwner	Yes	No (organization name)
projectVerifier	Yes	No (organization name)
subWatershed	Yes	Yes
watershed	Yes	Yes
story	Yes	Yes
storyTitle	Yes	Yes
projectSize	Yes	No
sectoralScope	Yes	Yes
certifications	Yes	Yes
sourceRegistry	Yes	No (organization name)
projectActivities	Yes	Yes
verificationMethod	Yes	Yes
carbonOffsetStandard	Yes	No (standard name)
approvedMethodologies	Yes	Yes
offsetGenerationMethod	Yes	Yes
ratings	Yes	No
cfcProjectId	Yes	No
cfcProjectPage	Yes	No (URL)
offsetProtocol	Yes	Yes
projectType	Yes	Yes
projectEndDate	Yes	No (date)
projectStartDate	Yes	No (date)
projectDesignDocument	Yes	No (URL)
location	Yes	no
tokenizationSource	Yes	No
verificationFrequency	Yes	Yes
measuredGHGs	Yes	Yes
creditingTerm	Yes	Yes (translate year to ano)
lookbackPeriod	Yes	Yes (translate year to ano)
leakageApproach	Yes	Yes
permanencePeriod	Yes	Yes
landOwnershipType	Yes	Yes
bufferPoolAccounts	Yes	Yes
eligibleActivities	Yes	Yes
monitoringFrequency	Yes	No
verificationMethods	Yes	Yes
additionalityApproach	Yes	Yes
additionalityAssessment	Yes	Yes
creditGenerationMethod	Yes	Yes
biocharApplicationType	Yes	Yes
baselineMethod	Yes	Yes
leakageAssessment	Yes	Yes
geographicApplicability	Yes	Yes
primaryImpact	Yes	Yes
biocharFeedstockMaterial	Yes	Yes
toucanProjectTokenId	Yes	No
vcsProjectId	Yes	No
additionalCertifications	Yes	Yes
allowsAggregatedProjects	Yes	No
monitoringReports	Yes	Yes
verificationReports	Yes	Yes
supplementalDatasets	Yes	Yes
cfcVintageYear	Yes	No (year)
cfcCreditSerialNumbers	Yes	No
toucanVintageID	Yes	No (int)

[S4mmyb]

@erikalogie can you take a look through this?

[blushi]

I don't think we need to translate regen:marketType, we don't really display the value directly in the UI but rather use the value to compare with our internal constant, see

regen-web/web-marketplace/src/lib/db/types/json-ld/terrasos-project-metadata.ts

Line 32 in 6049a68

export type MarketType = 'COMPLIANCE_MARKET' | 'VOLUNTARY_MARKET';

and then display relevant logic
If we translate it this means we would need different constants based on the selected language which complicates things unnessarily.

For regen:SDGs, we only specify the @id which then allows us to map it to a SDG image in sanity so I don't think we need to translate this either.

Generally, anything that is an @id or @type shouldn't get translated. So for object fields like regen:coBenefits, which has @id, @type, schema:name and regen:SDGs, did you mean by "Yes" that schema:name should be translated in particular?

[blushi]

Also for duration like regen:monitoringFrequency, how to translate those since there are using ISO 8601 duration format?

[erikalogie]

@erikalogie can you take a look through this?

LGTM aside from Marie's comments

[blushi]

@S4mmyb Here's an updated list of json fields to be translated. When we need to translate a value within a nested object, I separate the keys with a dot, this is how our translation process works. This way we can translate schema:name within approvedMethodologies for instance but not all the other schema:name values. So do you think we still want to translate all top level schema:name? like project or credit class names...

Within verificationReports it looks like we only store some schema:url so I excluded those. As well as any frequency/duration related fields which uses ISO 8601 format.

I've also included some fields that were listed but should be translated IMO:

• description of all project stakeholders
• some project page metadata fields

"schema:name", ???
"schema:description",
"regen:bioregion",
"regen:biomeType",
"regen:conservationStatus",
"regen:ecosystemType",
"regen:environmentType",
"regen:environmentalAuthority.schema:name",
"regen:managementAreas.regen:projectActivity",
"regen:projectDeveloper.schema:description",
"regen:projectMonitor.schema:description",
"regen:projectOperator.schema:description",
"regen:projectOwner.schema:description",
"regen:projectVerifier.schema:description",
"regen:subWatershed",
"regen:watershed",
"regen:sectoralScope",
"regen:certifications",
"regen:projectActivities",
"regen:verificationMethod",
"regen:approvedMethodologies.schema:itemListElement.schema:name",
"regen:offsetGenerationMethod",
"regen:offsetProtocol.schema:name",
"regen:projectType",
"regen:measuredGHGs",
"regen:leakageApproach",
"regen:landOwnershipType",
"regen:bufferPoolAccounts.schema:name",
"regen:eligibleActivities",
"regen:verificationMethods",
"regen:additionalityApproach",
"regen:additionalityAssessment",
"regen:creditGenerationMethod",
"regen:biocharApplicationType",
"regen:baselineMethod",
"regen:leakageAssessment",
"regen:geographicApplicability",
"regen:primaryImpact.schema:name",
"regen:biocharFeedstockMaterial",
"regen:additionalCertifications.schema:name",
"regen:supplementalDatasets.schema:name"

"regen:story",
"regen:storyTitle",
"regen:previewPhoto.schema:creditText",
"regen:galleryPhotos.schema:caption",
"regen:galleryPhotos.schema:creditText",
"schema:creditText",
"regen:storyMedia.schema:creditText"

[S4mmyb]

Hey @blushi, thanks for updating that. I was thinking about this more and I think To enhance accessibility, we recommend translating all schema:name values, covering names of projects, methodologies, standards, reports, and co-benefits. My rationale is that google translate will probably leave unique project names, organization names, and standards (e.g., “ICROA”) t untranslated which allows us to preserve brand integrity and recognition, while translating descriptive names (e.g., methodologies, reports, co-benefits) to ensure international users can fully understand the content and context.

I think we try that and see how it works, then for the edge cases we can always go back and update the ones it didn't do well?

[blushi]

So for "Verified Carbon Standard" credit class, I've done some tests and it will translate it as "Estándar de carbono verificado", is that fine?

[blushi]

I wasn't sure about additionalCertifications either, we have for instance the following in some batch metadata:

'regen:additionalCertifications': [
        {
          'schema:name': 'CCB-Gold',
          'schema:url': {
            '@type': 'schema:URL',
            '@value': 'https://verra.org/project/ccb-program/',
          },
        },
      ]

If we translate the schema:name in it, it will give "CCB-Oro"