From dd25b42f7bcdffed82ebc70aa5d8f8a15252800d Mon Sep 17 00:00:00 2001 From: Dennis Payk Date: Wed, 29 May 2024 09:16:29 +0200 Subject: [PATCH] Harmonize naming of Open Pioneer Trails (#105) --- CHANGELOG.md | 2 +- README.md | 2 +- docs/BestPractices.md | 4 ++-- docs/Glossary.md | 16 ++++++++-------- docs/Introduction.md | 2 +- docs/README.md | 2 +- docs/RepositoryGuide.md | 2 +- docs/internals/BuildTools.md | 2 +- docs/internals/Design_Phase2.md | 16 ++++++++-------- docs/internals/ServiceLayer.md | 2 +- docs/reference/Package.md | 2 +- docs/reference/Theming.md | 8 ++++---- docs/tutorials/HowToCreateAPackage.md | 2 +- docs/tutorials/HowToCreateAnApp.md | 6 +++--- docs/tutorials/HowToCreateUiComponents.md | 2 +- docs/tutorials/HowToPublishAPackage.md | 14 +++++++------- docs/tutorials/HowToThemeAnApp.md | 10 +++++----- docs/tutorials/HowToTranslateAnApp.md | 6 +++--- docs/tutorials/HowToUseAService.md | 4 ++-- docs/tutorials/HowToWriteTests.md | 2 +- src/index.html | 6 +++--- src/samples/i18n-howto/app/i18n/de.yaml | 2 +- src/samples/i18n-howto/app/i18n/en.yaml | 2 +- src/samples/map-sample/ol-app/MapApp.tsx | 2 +- typedoc.config.cjs | 2 +- 25 files changed, 60 insertions(+), 60 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 3e93da7..4ce5df2 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -14,5 +14,5 @@ ## 2024-03-14 -- Update to latest open pioneer trails packages +- Update to latest Open Pioneer Trails packages - Update to OpenLayers 9 diff --git a/README.md b/README.md index 1f7676e..4b5548a 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# Open Pioneer Starter +# Open Pioneer Trails Starter ![Build status](https://github.com/open-pioneer/trails-starter/actions/workflows/test-and-build.yml/badge.svg) ![Dependency audit](https://github.com/open-pioneer/trails-starter/actions/workflows/audit-dependencies.yml/badge.svg) diff --git a/docs/BestPractices.md b/docs/BestPractices.md index 120e299..975865e 100644 --- a/docs/BestPractices.md +++ b/docs/BestPractices.md @@ -89,7 +89,7 @@ Both `dependencies` and `peerDependencies` refer to packages required at runtime We'll reuse the rules defined in that post. Use `peerDependencies` if at least _one_ of these conditions apply: - Having multiple copies of a package would cause conflicts. - > This is especially the case for open pioneer packages as we do not support open pioneer packages in multiple versions. + > This is especially the case for Trails packages as we do not support Trails packages in multiple versions. > "plain" npm packages can often be duplicated though, if absolutely necessary. - The dependency is visible in your interface - You want the developer to decide which version to install @@ -104,7 +104,7 @@ You can use `devDependencies` to force a specific (e.g. very new) version to pro The guidelines above only leave very few occasions where a "normal" dependency is appropriate. Use `dependencies` if _all_ of the following is true: -- The dependency in question is not an open pioneer package +- The dependency in question is not a Trails package - Having multiple versions will not introduce conflicts (e.g. React should never be present more than once) - The usage of that package is entirely internal, i.e. not part of your package's interface. This could be the case for internal helpers, parsers, etc. diff --git a/docs/Glossary.md b/docs/Glossary.md index 29508e4..7264595 100644 --- a/docs/Glossary.md +++ b/docs/Glossary.md @@ -15,14 +15,7 @@ Apps are developed in application packages. ## Application package A package that provides an app (typically in `app.js` or `app.ts`). -Application packages are also pioneer packages. - -## Pioneer package - -A special package type that serve as the building blocks of an app. -Pioneer packages may define and use services and UI components. -The packages used by an app are automatically linked into the application. -The build system ensures that the code (and assets) required are automatically loaded. +Application packages are also Trails packages. ## Package @@ -44,3 +37,10 @@ References to services are handled by the system, which will inject appropriate Pioneer packages may be compiled (and distributed) independently from other packages or the context of a specific application. These packages can be linked together into an application using our build tooling. + +## Trails package + +A special package type for the Open Pioneer Trails framework that serve as the building blocks of an app. +Trails packages may define and use services and UI components. +The packages used by an app are automatically linked into the application. +The build system ensures that the code (and assets) required are automatically loaded. diff --git a/docs/Introduction.md b/docs/Introduction.md index 4437288..f0bd10f 100644 --- a/docs/Introduction.md +++ b/docs/Introduction.md @@ -1,6 +1,6 @@ # Introduction -The open pioneer client framework supports the creation of client side web applications. +The Open Pioneer Trails framework supports the creation of client side web applications. It offers a simple architecture where an application can be assembled from a set of packages. Packages are reusable components that can be used in multiple applications and with different configuration. When an application is built, it can be deployed either as a single (or multi-) page application or as an easily embeddable Web Component. diff --git a/docs/README.md b/docs/README.md index fb25386..5e7ac3e 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,4 +1,4 @@ -# Open Pioneer Documentation +# Open Pioneer Trails documentation ## Table of contents diff --git a/docs/RepositoryGuide.md b/docs/RepositoryGuide.md index a11cfe5..217b547 100644 --- a/docs/RepositoryGuide.md +++ b/docs/RepositoryGuide.md @@ -262,7 +262,7 @@ function MyComponent() { ### Vite [Vite](https://vitejs.dev/) is our main build tool and development server. -Custom functionalities (such as our specific pioneer-framework package support) are developed on top of Vite via plugins. +Custom functionalities (such as our specific Open Pioneer Trails framework package support) are developed on top of Vite via plugins. Vite reads the configuration file `vite.config.ts` on start, which can be customized to your liking (see [docs](https://vitejs.dev/config/)). diff --git a/docs/internals/BuildTools.md b/docs/internals/BuildTools.md index 3b43314..ea7c4a3 100644 --- a/docs/internals/BuildTools.md +++ b/docs/internals/BuildTools.md @@ -39,7 +39,7 @@ Reading and validation of the `build.config.mjs` are implemented here, as well a ### Overview -Every local package in a pioneer application contains a `build.config.mjs` and a `package.json` file, together defining the package's metadata. +Every local package in an Open Pioneer Trails application contains a `build.config.mjs` and a `package.json` file, together defining the package's metadata. Package metadata includes: - The packages name, version, etc. diff --git a/docs/internals/Design_Phase2.md b/docs/internals/Design_Phase2.md index 8329d44..cf31eb9 100644 --- a/docs/internals/Design_Phase2.md +++ b/docs/internals/Design_Phase2.md @@ -2,9 +2,9 @@ ## Introduction -This document contains the design for the second implementation phase of the pioneer framework. +This document contains the design for the second implementation phase of the Open Pioneer Trails framework. The goal of this phase is to enable development across multiple repositories, i.e. using non-local packages -in an open pioneer app and sharing such packages with other developers. +in an Open Pioneer Trails app and sharing such packages with other developers. Note that most aspects in this document are concerned with _packages_, not with _apps_. Building and distributing an application is a problem solved with phase 1, and only a few modifications @@ -32,13 +32,13 @@ It may in fact be a disadvantage because it makes generated code harder to read - A build tool that compiles a single package, handling TypeScript/JavaScript/JSX, CSS and assets such as README or LICENSE files. - A tool to publish such a compiled package to a registry -- Existing build tools must be able to handle external packages with pioneer extensions +- Existing build tools must be able to handle external packages with Open Pioneer Trails extensions - Configuration / Documentation: How to build and host api docs - Documentation: How to use an external package ## Assumptions -- All packages will ultimately be built using vite, with our pioneer vite plugin enabled. +- All packages will ultimately be built using vite, with our Open Pioneer Trails vite plugin enabled. Applications will always contain our matching runtime package. This gives us some leeway w.r.t. special vite imports (e.g. `?inline`) - we can just pass them through and not replace them at all. @@ -112,22 +112,22 @@ It may in fact be a disadvantage because it makes generated code harder to read It is easier and more performant to put metadata in the `package.json`. It does not have to be edited by hand and we have to open the `package.json` anyway during package discovery. - This makes the answer to the question "does this package use open pioneer features" very quick to answer. + This makes the answer to the question "does this package use Open Pioneer Trails features" very quick to answer. ## Build plugin -The existing vite plugin must be extended to handle pioneer packages from `node_modules`. +The existing vite plugin must be extended to handle Open Pioneer Trails packages from `node_modules`. Vite handles node packages from `node_modules` just fine on its own, but our own build plugin ignores them currently. They must not be be ignored in the future because the services, properties and styles from such a package must be linked into the application, which is the responsibility of our plugin. -Vite build plugin will scan all dependencies (local and non-local) of an app to check whether they are either local or use pioneer extensions (check for presence of `openPioneer` in `package.json`). +Vite build plugin will scan all dependencies (local and non-local) of an app to check whether they are either local or use Open Pioneer Trails extensions (check for presence of `openPioneer` in `package.json`). For local packages, the process stays as it is. For non-local packages (in `node_modules`) the recursive search continues until a "non-pioneer" package is found, which will then be ignored just as before. All services, properties etc. of discovered packages will then be linked into the application. -Note that this search will not discover pioneer packages that are dependencies of "plain" packages, i.e. +Note that this search will not discover Trails packages that are dependencies of "plain" packages, which means "app" -> "package without openPioneer" -> "package with openPioneer" diff --git a/docs/internals/ServiceLayer.md b/docs/internals/ServiceLayer.md index aabbc11..550d798 100644 --- a/docs/internals/ServiceLayer.md +++ b/docs/internals/ServiceLayer.md @@ -1,6 +1,6 @@ # Service Layer -This document contains details about the implementation of the pioneer runtime's service layer. +This document contains details about the implementation of the Open Pioneer Trails runtime's service layer. It should aid developers to gain an understanding of the implementation in order to maintain or extend it. The service layer provides a generic dependency injection mechanism in which services can be defined. diff --git a/docs/reference/Package.md b/docs/reference/Package.md index 2385f09..c0c7349 100644 --- a/docs/reference/Package.md +++ b/docs/reference/Package.md @@ -2,7 +2,7 @@ ## Introduction -This document specifies the structural requirements for an open pioneer package in the source directory. +This document specifies the structural requirements for a Trails package in the source directory. > This specification applies to both apps and "normal" packages. > Apps are simply packages that expose a web component: they may use all package features such as services etc. diff --git a/docs/reference/Theming.md b/docs/reference/Theming.md index 277b785..bd653de 100644 --- a/docs/reference/Theming.md +++ b/docs/reference/Theming.md @@ -2,7 +2,7 @@ When developing Open Pioneer Trails applications, arbitrary [React](https://reactjs.org/) components can be used to create the user interface. However, we mostly use pre-defined components from the Chakra UI framework. -Chakra UI comes with a theming mechanism that is re-used in trails and briefly explained here. +Chakra UI comes with a theming mechanism that is re-used in Open Pioneer Trails and briefly explained here. To get an example of how to create a theme for your app, refer to [How To Theme An App](../tutorials/HowToThemeAnApp.md). @@ -19,12 +19,12 @@ There are two internal levels of theming and a third level for an app-specific c The first level is Chakra UI's default theme which defines the _default look_ of Chakra UI components and is part of Chakra UI. -The second internal level is the Trails base theme which is part of the Trails Core Packages. +The second internal level is the Trails base theme which is part of the Trails core packages. It defines common variables ([semantic tokens](https://chakra-ui.com/docs/styled-system/component-style)) and a default color scheme that is used as a default color scheme for all Chakra UI components. This theme is active by default in Trails applications, but it is also designed to be extended. Most custom themes are expected to extend this theme (via Chakra's `extendTheme()` function) while making only minor adjustments. -The Trails base theme will be extended in future releases of the Trails Core Packages. +The Trails base theme will be extended in future releases of the Trails core packages. The third level of theming is a custom theme that can be passed to a Trails app via the optional `theme` option in `createCustomElement`. When specified, the custom theme replaces the Trails base theme as the application's active theme. @@ -37,4 +37,4 @@ Changes to the theme will therefore always affect multiple component instances. To style _specific_ elements in a different way, the developer has to use CSS rules or inline styles. The [`Sample UI`](https://github.com/open-pioneer/trails-core-packages/tree/main/src/samples/chakra-sample/chakra-app) -app in the Trails Core packages provides an example for a custom theme. +app in the Trails core packages provides an example for a custom theme. diff --git a/docs/tutorials/HowToCreateAPackage.md b/docs/tutorials/HowToCreateAPackage.md index 70ed955..877943d 100644 --- a/docs/tutorials/HowToCreateAPackage.md +++ b/docs/tutorials/HowToCreateAPackage.md @@ -34,7 +34,7 @@ We will create a package called `hello-world` that exports a simple function: import { defineBuildConfig } from "@open-pioneer/build-support"; // The empty object is the minimal configuration. -// We're not going to use any custom features from the pioneer framework for now. +// We're not going to use any custom features from the Open Pioneer Trails framework for now. export default defineBuildConfig({}); ``` diff --git a/docs/tutorials/HowToCreateAnApp.md b/docs/tutorials/HowToCreateAnApp.md index f396d89..15f3178 100644 --- a/docs/tutorials/HowToCreateAnApp.md +++ b/docs/tutorials/HowToCreateAnApp.md @@ -11,7 +11,7 @@ This repository comes prepared with an empty app in `src/apps/empty`, which is e To create the application package for an app, first initialize a `package.json` file in a new directory. Application packages should by convention be placed in `src/apps/`, but technically they may be placed anywhere in the `src` directory. -All pioneer packages are node packages to benefit from (p-)npm's dependency management. +All Trails packages are node packages to benefit from (p-)npm's dependency management. Create a very simple [`package.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-json) such as this: ```jsonc @@ -66,11 +66,11 @@ const Element = createCustomElement({ customElements.define("my-app-element", Element); ``` -This is the setup required for a minimal pioneer application: +This is the setup required for a minimal Open Pioneer Trails application: - **(1)** `createCustomElement` is the central framework function responsible for defining the actual web component. - It is exported by `@open-pioneer/runtime`, a package all pioneer applications must depend on. + It is exported by `@open-pioneer/runtime`, a package all Open Pioneer Trails applications must depend on. - **(2)** The special `open-pioneer:app` module provides automatically gathered metadata about your application. diff --git a/docs/tutorials/HowToCreateUiComponents.md b/docs/tutorials/HowToCreateUiComponents.md index e9f29d8..e207581 100644 --- a/docs/tutorials/HowToCreateUiComponents.md +++ b/docs/tutorials/HowToCreateUiComponents.md @@ -1,6 +1,6 @@ # How to create UI components -When developing applications with the open pioneer client framework, [React](https://reactjs.org/) can be used to create UI components. +When developing applications with the Open Pioneer Trails client framework, [React](https://reactjs.org/) can be used to create UI components. We can also use pre-defined components from the [Chakra UI](https://chakra-ui.com/) framework. ## Documentation diff --git a/docs/tutorials/HowToPublishAPackage.md b/docs/tutorials/HowToPublishAPackage.md index 592f109..800b133 100644 --- a/docs/tutorials/HowToPublishAPackage.md +++ b/docs/tutorials/HowToPublishAPackage.md @@ -1,14 +1,14 @@ # How to publish a package -This tutorial describes how to share a pioneer package with other developers. +This tutorial describes how to share a Open Pioneer Trails package with other developers. You can skip this document if you're just working in the context of a single application. Until now, this manual has only been concerned with building an _application_, possibly including a set of _local_ packages. The result of building an application is always a set of static files (.i.e. `.html`, `.js`, etc.) that can be interpreted by a browser. This output is ideal for distributing a final application, but it is not suitable for sharing reusable parts of your application. -One of the key advantages of the open pioneer client framework is the ability to scale up application development by sharing reusable application components as packages. -Shared open pioneer packages are similar to "plain" node packages (in fact, they _are_ node packages), but they come with the additional feature set you have learned already: +One of the key advantages of the Open Pioneer Trails client framework is the ability to scale up application development by sharing reusable application components as packages. +Shared Trails packages are similar to "plain" node packages (in fact, they _are_ node packages), but they come with the additional feature set you have learned already: services of a package are automatically started when needed, styles are automatically applied, etc. There are some things to consider and a few steps to follow when indenting to share a package with other developers. @@ -34,7 +34,7 @@ We will first discuss the underlying concepts and then work through a specific e - **Package installation** After a package has been published, it can simply be installed in any project, e.g. by executing `pnpm add`. - Our build tools automatically detect pioneer packages in an app's dependency graph. + Our build tools automatically detect Trails packages in an app's dependency graph. A package installed this way should work the same way _as if_ it were developed locally. ### Package compilation @@ -46,7 +46,7 @@ It can be installed by adding [`@open-pioneer/build-package-cli`](https://www.np $ pnpm add -w -D @open-pioneer/build-package-cli ``` -It is designed to be invoked from the source directory of a pioneer package and reads its configuration from that package's `package.json` and `build.config.mjs` (see [Reference](../reference/Package.md#publishconfig)). +It is designed to be invoked from the source directory of a Trails package and reads its configuration from that package's `package.json` and `build.config.mjs` (see [Reference](../reference/Package.md#publishconfig)). After successful execution, it will have assembled a compiled version of that package in the `dist` directory (in that package's source directory). `build-pioneer-package` also performs some validation to enforce best practices and to catch common errors. @@ -141,7 +141,7 @@ Package compilation involves the following steps: Most properties from your package's source `package.json` will simply be copied into the generated `package.json` (such as `name`, `version` and many more). When generating the `package.json`, `build-pioneer-package` also takes into account your package's metadata from the `build.config.mjs`: it will make entry points public (via `exports`) and include - information about services and other open pioneer features using the `openPioneerFramework` property. + information about services and other Open Pioneer Trails features using the `openPioneerFramework` property. - **Copy auxiliary files.** @@ -395,7 +395,7 @@ We have also been told to configure `publishConfig.directory`: } ``` -Because the core package is a pioneer package, we have added it as a `peerDependency` (see [Best Practices](../BestPractices.md#dependency-management)). +Because the core package is a Trails package, we have added it as a `peerDependency` (see [Best Practices](../BestPractices.md#dependency-management)). We also added `linkDirectory: false`, see [Publishing](#publishing). #### Adding required files diff --git a/docs/tutorials/HowToThemeAnApp.md b/docs/tutorials/HowToThemeAnApp.md index eec31fa..3599099 100644 --- a/docs/tutorials/HowToThemeAnApp.md +++ b/docs/tutorials/HowToThemeAnApp.md @@ -8,7 +8,7 @@ mechanism in Open Pioneer Trails apps, refer to [Theming](../reference/Theming.m To show how a custom theme for an app can be created, we will extend the empty app (at `src/apps/empty`). -By default, the app is shown in a theme specified in the Trails Core packages. +By default, the app is shown in a theme specified in the Trails core packages. To overwrite some or all styles (e.g. the "trails" color scheme), a custom app-theme can be created. ## Create custom theme @@ -102,13 +102,13 @@ export const theme = extendTheme( ``` - **(1)** Import the `extendTheme` helper function. -- **(2)** Import the trails base theme from the "@open-pioneer/base-theme" package. -- **(3)** Use `extendTheme` to create an own theme based on the trails base theme. +- **(2)** Import the Trails base theme from the "@open-pioneer/base-theme" package. +- **(3)** Use `extendTheme` to create an own theme based on the Trails base theme. - **(3.1)** Chakra UI theming object that defines the custom theme. (The object specified here is only used as an example.) -- **(3.2)** Specify the theme to extend (here: the trails base theme). +- **(3.2)** Specify the theme to extend (here: the Trails base theme). -Hint: The trails base-theme introduces some special semantic tokens. +Hint: The Trails base theme introduces some special semantic tokens. For information about which values are available, see the base-theme core package code. ### Use a Chakra UI color scheme diff --git a/docs/tutorials/HowToTranslateAnApp.md b/docs/tutorials/HowToTranslateAnApp.md index 183fea9..c5c0c2c 100644 --- a/docs/tutorials/HowToTranslateAnApp.md +++ b/docs/tutorials/HowToTranslateAnApp.md @@ -1,6 +1,6 @@ # How to translate an app -To show how we can use I18n in our pioneer apps, we will extend the empty app (at `src/apps/empty`). +To show how we can use I18n in our Open Pioneer Trails apps, we will extend the empty app (at `src/apps/empty`). By default, the empty app is prepared to support I18n with locale `en`. We will add support for another language (locale `de`) and demonstrate advanced features of [FormatJS](https://formatjs.io/) Intl. @@ -36,7 +36,7 @@ We need to create the file in the `i18n` folder. The naming schema of the file i # src/apps/empty/i18n/de.yaml messages: heading: I18n HowTo - text: Wie lässt sich I18n in Pioneer Apps nutzen? + text: Wie lässt sich I18n in Open Pioneer Trails Apps nutzen? ``` By default, the app uses the browser settings or system default for determining the locale. @@ -103,7 +103,7 @@ Now we are able to force the locale with `lang` parameter: [http://localhost:5173/sites/empty/?lang=de](http://localhost:5173/sites/empty/?lang=de) or [http://localhost:5173/sites/empty/?lang=en](http://localhost:5173/sites/empty/?lang=en) > **Note** -> The integration of I18n works the same way for pioneer packages. We have to add the `i18n` configuration in `build.config.mjs` and matching yaml files for each language in the `i18n` folder. For each app/language combination, the build tool collects the YAML files of the app and the used packages and merges them into a flattened JSON structure. +> The integration of I18n works the same way for Trails packages. We have to add the `i18n` configuration in `build.config.mjs` and matching yaml files for each language in the `i18n` folder. For each app/language combination, the build tool collects the YAML files of the app and the used packages and merges them into a flattened JSON structure. > As mentioned in [I18nFormat](../reference/I18nFormat.md) we can override yaml entries from packages in our app yaml. Please check the [`i18n-sample`](https://github.com/open-pioneer/trails-core-packages/tree/main/src/samples/i18n-sample) app as a practical example for this topic. ## Using advanced features of FormatJS Intl diff --git a/docs/tutorials/HowToUseAService.md b/docs/tutorials/HowToUseAService.md index ccbb278..c57a30d 100644 --- a/docs/tutorials/HowToUseAService.md +++ b/docs/tutorials/HowToUseAService.md @@ -1,6 +1,6 @@ # How to use a service -Services are one of the central mechanisms of code sharing in an open pioneer client application. +Services are one of the central mechanisms of code sharing in an Open Pioneer Trails client application. Instead of using global variables (or singletons), services are started per-application instance. Builtin dependency injection support allows services to declare their dependencies on other services. @@ -36,7 +36,7 @@ export default defineBuildConfig({ The package providing the implementation of a service must be declared as a dependency in the `package.json`. Luckily, the empty app already depends on the `@open-pioneer/runtime` package, so we don't have to do anything in this case. -React components can use [hooks](https://reactjs.org/docs/hooks-intro.html) to interact with the pioneer framework. +React components can use [hooks](https://reactjs.org/docs/hooks-intro.html) to interact with the Open Pioneer Trails framework. One of which is the `useService` hook, we will use below. We extend the UI of the empty app to add our custom class: diff --git a/docs/tutorials/HowToWriteTests.md b/docs/tutorials/HowToWriteTests.md index 1de6ef6..04a54e1 100644 --- a/docs/tutorials/HowToWriteTests.md +++ b/docs/tutorials/HowToWriteTests.md @@ -203,7 +203,7 @@ Recommended libraries: ## Test utilities -The package `@open-pioneer/test-utils` provides helpers to test components of a pioneer application: +The package `@open-pioneer/test-utils` provides helpers to test components of an Open Pioneer Trails application: - The application itself (that is, the web component). Web components can be mounted in the DOM and their children can be searched. diff --git a/src/index.html b/src/index.html index 1c09f4c..f63fca2 100644 --- a/src/index.html +++ b/src/index.html @@ -3,7 +3,7 @@ - Open Pioneer Test Site + Open Pioneer Trails Test Site -

Open Pioneer Test Site

+

Open Pioneer Trails Test Site

-

Welcome to the open pioneer client framework!

+

Welcome to the Open Pioneer Trails client framework!

Empty App

The following site has been prepared with an empty app:

diff --git a/src/samples/i18n-howto/app/i18n/de.yaml b/src/samples/i18n-howto/app/i18n/de.yaml index 703653f..b93cede 100644 --- a/src/samples/i18n-howto/app/i18n/de.yaml +++ b/src/samples/i18n-howto/app/i18n/de.yaml @@ -2,7 +2,7 @@ # (might be empty if all messages are defined in the packages used by this app) messages: heading: I18n HowTo - text: Wie lässt sich I18n in Pioneer Apps nutzen? + text: Wie lässt sich I18n in Open Pioneer Trails Apps nutzen? interpolation: heading: Beispiel für Interpolation (dynamische Werte) value: Hallo {name} diff --git a/src/samples/i18n-howto/app/i18n/en.yaml b/src/samples/i18n-howto/app/i18n/en.yaml index 65c704d..f86036e 100644 --- a/src/samples/i18n-howto/app/i18n/en.yaml +++ b/src/samples/i18n-howto/app/i18n/en.yaml @@ -2,7 +2,7 @@ # (might be empty if all messages are defined in the packages used by this app) messages: heading: "I18n HowTo" - text: "How to use I18n in pioneer apps?" + text: "How to use I18n in Open Pioneer Trails apps?" interpolation: heading: "Interpolation Example (dynamic values)" value: "Hello {name}" diff --git a/src/samples/map-sample/ol-app/MapApp.tsx b/src/samples/map-sample/ol-app/MapApp.tsx index f5e9551..596d5ce 100644 --- a/src/samples/map-sample/ol-app/MapApp.tsx +++ b/src/samples/map-sample/ol-app/MapApp.tsx @@ -47,7 +47,7 @@ export function MapApp() { textAlign="center" py={1} > - Open Pioneer - Map Sample + Open Pioneer Trails - Map Sample } > diff --git a/typedoc.config.cjs b/typedoc.config.cjs index 7cbf691..56bcf45 100644 --- a/typedoc.config.cjs +++ b/typedoc.config.cjs @@ -9,7 +9,7 @@ console.info("Creating documentation for packages:", documentedPackages); // See https://typedoc.org/options/ module.exports = { - name: "Open Pioneer Packages", + name: "Trails Packages", readme: "none", out: "dist/docs", entryPointStrategy: "packages",