Texts in Apps and Studio

[nkylstad]

Description

Overview issue of work that needs to be done on text handling (App and Studio). (Moved analysis to a separate issue #8619)

App text handling

• Make sure app texts and standard texts have the same format
• Standard texts on both Altinn and org level
• Make it possible to override standard texts from app
• App API should return a single resource of texts for a given language
• App frontend should use a single resource of texts for a given langugage

Studio - editing texts

• Org repos for shared resources (inkl. for Altinn) to store standard texts in Studio
• New text editor with markdown support
• Possible to edit texts directly in components in ui-editor?
• Select which org texts should be included for app
• Deploy of standard texts

Open questions from #8619

Text microservice

• [ ] Create new microservice (Text), or keep texts in Storage?
  • [ ] Shared platform resource, or a resource within each service owners app cluster?
• [ ] Should it be possible to deploy JUST texts from app?

Configuration

• [ ] How do we configure which standard/org texts are included?
  • Suggestion is that Altinn standard texts are always included, and a setting in applicationMetadata.json for any org related standard texts.
• [ ] Can there be more than 1 set of standard texts for an org? How to configure merge hierarchy?
  • Config could be a list, in order of "importance".

Format

• [ ] Simple JSON key/value pair or something else (to support f.eks. multiline texts better)?
  • Will a good markdown editor be a good enough solution for this?
• [ ] Do we need an export format for use in other applications (f.ex. CSV -> excel?)

Tasks

Common

• [x] #8619
  • [ ] Some open questions that should be considered
• [x] #4791

App

• [ ] Update app frontend to use single text resource (instead of handling app/standard texts separately)
• [ ] API to fetch/merge app texts and standard/org texts.

Studio

• [ ] Build a new text editor
  • Related Epic: #489
  • [ ] Determine and document requirements
  • [ ] POC/MVP
• [ ] Create org repos for shared resources
• [ ] Support for deploy of standard/org texts independently of apps
• [ ] Tools for upgrading existing text resource files to new format

Design

New design for language handling (Figma sketches from hackaton week 24, 2022, @mrosvik) The design is based on the redesign of studio that Thord did.

Editing texts directly in the GUI editor

App developers should be able to edit text directly in the components, without first having to add them to the language page.

The video below shows:

• When adding text first time to a component, app developers should get a list of existing texts, but should be able to add new texts as well from this context.
• New texts that are added should automatically get an ID. For example, if you have written "Fornavn" in the label input, the ID is automatically generated based on the input. App developers should be able to manually edit the ID if desired, under "Edit".
• The field you have focus on gets language fields in the right margin.
• The field you have focus on gets a tool-line (if it is a markdown-field).

https://user-images.githubusercontent.com/1464915/174284284-662b0974-e93a-4919-8e7e-43b2573a95ab.mov

Stand-alone language page

App developers should get an overview of all the texts used in the app. It should be possible to add new texts as well from this page.

The video below shows:

• Next to the ID-field there is a menu with "Copy" and "Delete" functionality
• Next to search there is a filter for showing only IDs like "...."
• The right margin should show which languages is active for the app. Bokmål, Nynorsk and English could possible be active as default to encourage app developer to enter these translations? Other languages are added as needed. It should be possible to delete languages from the menu next to the language and set it as default. From the lists of languages it shoud also be possible to show/hide them from the overview (with the eye-icon)
• Possible addition: Under each ID there could be a list showing where the ID is in use in the app, with link to the component in GUI.

https://user-images.githubusercontent.com/1464915/174288232-16fd0c5e-5932-4c6c-951d-a92cde963eef.mov

Auto saving and error message

The video below shows:

• App developers should get info saying that the content is autosaved when they have made changes
• App developers should get a warning if something is wrong and the content is not saved

https://user-images.githubusercontent.com/1464915/174286582-7a2cf16f-529d-424d-8de2-c6a9c4ec6c0a.mov

Add new texts

The video below shows:

• When adding a new text, app developers should get a list of existing texts/IDs, both local texts and global texts from higher levels that they can choose to override. When overriding a standard Altinn text, they will get a message informing about overwriting.

https://user-images.githubusercontent.com/1464915/174286429-4a7a38db-f8ec-473c-bed6-a4744b5ad256.mov

[altinnadmin]

@nkylstad I really like this :+1:. A few comments:

1. Key/value format. I agree, we should switch to a pure key/value format. Also using "." for future intellisense should be mentioned (even if not part of scope)
2. Merge time. Doing merge during deploy causes problems for local development, since there are no deploy there. Could having a "Update texts"-button in Designer be a better approach, so that the texts from Altinn and org is stored in app repo with versioning, and merge can then be done runtime?
3. Storage. Could we use app API as source with cosmos only as fallback? (for when an app has been deleted, better performance, better distribution and for easier local testing)
4. Fallback-language. I think we should switch to using en as default fallback-language for missing texts.

[nkylstad]

@altinnadmin Thanks for the comments! I have updated the conclusion part of the issue:

1. Explicitly say we should switch to a pure key/value format, and added a comment about using ".".
2. Good point. I have updated the conclusion to go back to merging at runtime, storing standard texts in app repo, and allowing app developer to trigger update.
3. I agree that the app API for fetching texts should be used in most cases, that was not so clear. I still think the actual merge should be done in storage, as there are other parts of the solution (f.ex. inbox) that might have a need for texts, but the app could cache the result so that we don't call storage when we don't need to.
4. Agreed, added a comment about that in the conclusion.

[acn-sbuad]

A consideration should be how an app developer can override a text that is based on a variable. E.g. app title for instance. Hdir have expresed the need to use a shorter version of their app title on the receipt page in order to support mobile view for instance.

[SandGrainOne]

No close, just postpone.

[mrosvik]

La til et kapittel om Design nederst i Epicen med Figma-skisser fra hackaton denne uka. Flytt gjerne om det ligger feil sted.

[nkylstad]

Closing this issue, as we will not pursue the structural changes further at this stage. Will open separate issues for working on the text editor in Studio, as well as re-use of texts.