fix: remove non-required docs, as already added in Docs repo

docs/02-Writing-Docs.md → docs/01-Writing-Docs.md

@@ -1,45 +1,34 @@
-This document outlines how documentation is handled in Phoenix.
+This document explains the process for managing documentation in Phoenix Code.
 
 ## The `docs` folder
-The `docs` folder in Phoenix repo is the main code/API/Extension
-docs folder for Phoenix. Most of the Phoenix GitHub Wiki is
-autogenerated from the contents of this folder.
+The docs folder in the Phoenix repository contains guidelines for writing docs and adding translations. Most of the GitHub Wiki is autogenerated from this folder, covering how to update these aspects in your Phoenix repository.
 
-### Docs Folder Structure
-There are two main components to the docs folder:
+> The contents of the `docs` folder are automatically pushed into Github Wiki. Make changes to Markdown files in this folder to update wiki entries.
 
-1. The contents of the `docs` folder are automatically pushed into gitHub wiki
-   as a subfolder `generatedDocs`. Make changes to Markdown files in this folder
-   to update wiki entries.
-2. The docs in the `docs/generatedApiDocs` are autoGenerated API docs from source. These
-   `markdown` docs should never be manually edited as their contents will be reset when autogenerated
-   and all manually made changes will be lost.
 
 ## How To Write API docs
 This section covers how API docs are auto generated and how you can update API docs.
 
-To Include any `.js` file containing [JSDoc](https://jsdoc.app/) in Phoenix API docs,
+To include any `.js` file containing [JSDoc](https://jsdoc.app/) in Phoenix Code API docs,
 have this comment in any part of the file:
 ```js
 // @INCLUDE_IN_API_DOCS 
 ```
 
 ### Writing JSDoc in source
 Let us consider this example source file [src/utils/Metrics.js](https://github.com/phcode-dev/phoenix/blob/main/src/utils/Metrics.js).
-The file is created with [JSDoc](https://jsdoc.app/) compliant source code comments. Make changes to
-the source code comments as required.
+The file is created with [JSDoc](https://jsdoc.app/) compliant source code comments. Make changes to the source code comments as required.
 
-When you run `npm run createJSDoc` or `npm run build` the corresponding docs for the js file are automatically generated at [docs/generatedApiDocs/utils/Metrics-API.md](https://github.com/phcode-dev/phoenix/blob/main/docs/generatedApiDocs/utils/Metrics-API.md).
+When you run `npm run createJSDoc` or `npm run build` the corresponding docs for the js file are automatically generated at [docs/API-Reference/utils/Metrics-API.md](https://github.com/phcode-dev/phoenix/blob/main/docs/API-Reference/utils/Metrics.md).
 
-The generated docs should be pushed to Phoenix repo if there are any doc changes.
-Once the changes are pushed, the build system will update the docs in all
-[wikis](https://github.com/phcode-dev/phoenix/wiki)/
-[doc](https://docs.phcode.dev/) sites automatically.
+The generated docs should be pushed to Docs repository if there are any doc changes.
+Once the changes are pushed, the build system will update the docs in
+[doc](https://docs.phcode.dev/) site automatically.
 
 ## JSDoc Examples
 This section outlines the various tags available in JSDoc to style docs with examples.
 
-note: All comment blocks with the `@private` tag will be ignored and won't appear in the docs.
+> All comment blocks with the `@private` tag will be ignored and won't appear in the docs.
 
 ### 1. Declaring a Module with `@module` tag
 
@@ -64,7 +53,7 @@ Use this to declare top level JS modules
   */
 ```
 
-Will Result in the following Markdown
+This will result in the following Markdown
 > ## utils/Metrics
 > The Metrics API can be used to send analytics data to track feature usage in accordance with users privacy settings.
 >`Status: Internal - Not to be used by third party extensions.`
@@ -87,11 +76,11 @@ Use this to put custom markdown anywhere in the doc file.
  */
 ```
 
-Will Result in the following Markdown
+This will result in the following Markdown
 > ## API
 >This section outlines the properties and methods available in this module
 
-### 3. types/constants using `@type` or `const`
+### 3. types/constants using `@type` or `@const`
 
 Use this to put constants or type definitions
 
@@ -103,7 +92,7 @@ Use this to put constants or type definitions
 const MAX_AUDIT_ENTRIES = 3000;
 ```
 
-Will Result in the following Markdown
+This will result in the following Markdown
 > ## MAX_AUDIT_ENTRIES
 >
 >The maximum number of audit entries; default is 3000.
@@ -137,7 +126,7 @@ const EVENT_TYPE = {
 Will Result in the following Markdown
 > ## EVENT_TYPE
 > The Type of events that can be specified as an `eventType` in the API calls.
->### Properties
+> ### Properties
 >`PLATFORM`, `PROJECT`, `THEMES`
 >
 > Type: [Object]
@@ -161,19 +150,19 @@ const EVENT_TYPE = {
 };
 ```
 
-Will Result in the following Markdown
+This will result in the following Markdown
 > ## EVENT_TYPE
 > The Type of events that can be specified as an `eventType` in the API calls.
 >
 > Type: [Object]
->### Properties
+> ### Properties
 >
 >*   `PLATFORM` **[string]**
 >*   `PROJECT` **[string]**
 >*   `THEMES` **[string]**
 
 
-### 5. Function docs with `@function` or `method`
+### 5. Function docs with `@function` or `@method`
 
 Use this to document a function and its arguments/returns/exceptions.
 
@@ -194,16 +183,16 @@ Use this to document a function and its arguments/returns/exceptions.
 function countEvent(eventType, count) {}
 ```
 
-Will Result in the following Markdown:
+This will result in the following Markdown:
 
 > ## countEvent
 > log a numeric count >=0
 > Type: [function][2]
->### Parameters
+> ### Parameters
 >*   `eventType` **([EVENT_TYPE] | [string])** The kind of Event Type that needs to be logged- should be a js var compatible string.
      Some standard event types are available as `EVENT_TYPE`.
 >*   `count` **[number]** > \=0
->### Examples
+> ### Examples
 >To log that user clicked searchButton 5 times:
 >```javascript
 >Metrics.countEvent(Metrics.EVENT_TYPE.UI, 5);

docs/03-Adding-Translations.md → docs/02-Adding-Translations.md

@@ -1,6 +1,6 @@
-This document outlines how to add support for various local languages in Phoenix.
+This document outlines how to add support for various local languages in Phoenix Code.
 
-Phoenix currently supports over 35 languages, primarily through automatic translations using AWS/Google Translate.
+Phoenix Code currently supports over 35 languages, primarily through automatic translations using AWS/Google Translate.
 
 ## Quick start
 
@@ -9,8 +9,8 @@ Phoenix currently supports over 35 languages, primarily through automatic transl
     or 
 2. Follow the below section on [Adding a new locale translation](Adding a new locale translation)
 
-### I want to correct some translations in my language
-To update translations for your language, such as French.
+### Update translations for a language
+To update translations for your language, let's say French.
 Follow the below steps:
 1. Find out the language code for your language
 from [ISO-Language code](https://www.w3schools.com/tags/ref_language_codes.asp). For French, this is `fr`.
@@ -21,49 +21,41 @@ from [ISO-Language code](https://www.w3schools.com/tags/ref_language_codes.asp).
 This folder contains all the localised strings. Each sub folder corresponds to an [ISO-Language code](https://www.w3schools.com/tags/ref_language_codes.asp).
 
 ### The `src/nls/root` folder
-A special folder called the `root` folder houses the reference english translations from which all other locale
-translations are derived. The `root` folder has three main files:
+A special folder called the `root` folder houses the reference English translations from which all other locale translations are derived. The `root` folder has three main files:
 1. `strings.js` - The full list of translated text.
-2. `strings-app.js` - The list of language code to localized language name mapping. This will be used in the switch
-language dialogue in debug menu.
+2. `strings-app.js` - The list of language code to localized language name mapping. This will be used in the switch language dialogue in debug menu.
 3. `urls.js` - local specific URLs.
 
 ### The `src/nls/<locale>` folder
 Each `src/nls/<locale>` folder contains similar files, plus a few additional ones:
-1. `expertTranslations.json` where you can provide expert translations for specific english strings to locale strings.
-This expert translation will be used instead of machine translations if present for a string.
+1. `expertTranslations.json` where you can provide expert translations for specific English strings to locale strings. This expert translation will be used instead of machine translations if present for a string.
 2. `strings.js` - The full list of translated text for the locale.
-3. Apart from the above tow there are 2 autogenerated files that should not be edited: `lastTranslated.json` and
-`lastTranslatedLocale.json`.
+3. Apart from the above two there are 2 autogenerated files that should not be edited: `lastTranslated.json` and `lastTranslatedLocale.json`.
 
-## Autogenerated and manual translations
-When any string changes are made to `src/nls/root/strings.js` or any `src/nls/<locale>/strings.js`,
-it will automatically be scanned by GitHub Actions and the corresponding translations will be generated.
-A pull request will be raised with the new translations.
+## Autogenerated and Manual translations
+When any string changes are made to `src/nls/root/strings.js` or any `src/nls/<locale>/strings.js`, it will automatically be scanned by GitHub Actions and the corresponding translations will be generated. A pull request will be raised with the new translations.
 
-You can also run the translation command locally if you have the AWS/GCP keys with the command. This is
-mostly FYI for phoenix internal devs.
+You can also run the translation command locally if you have the AWS/GCP keys with the command. This is mostly FYI for phoenix internal devs.
 ```bash
 npm run _translateStrings
 ```
 
 ### Skipping auto translate
 For some strings we may not want to translate them. For Example, for the keyboard shortcut string key `"KEYBOARD_CTRL": "Ctrl"`
-we don't want it translated to any language. Just add another key appending `_DO_NOT_TRANSLATE` to the key
-to disable automatic translations Eg. `"KEYBOARD_CTRL_DO_NOT_TRANSLATE": "true"` just below the original key. 
+we don't want it translated to any language. Just add another key appending `_DO_NOT_TRANSLATE` to the key to disable automatic translations Eg. `"KEYBOARD_CTRL_DO_NOT_TRANSLATE": "true"` just below the original key. 
 
 ### Adding expert/manual translation overrides
 We may want to add locale specific expert translation if the autogenerated translation is not good.
 For Eg. consider the key `"LIVE_DEV_LOADING_ERROR_MESSAGE": "Unable to load Live Preview page."`, and specify a manual translation in ro (Romanian). We can add a mapping in the file `nls/ro/expertTranslations.json` with
 the following string `"Unable to load Live Preview page.": "Imposibil de a încărca pagina Live Development"` .
 
-When the translation jobs run the next time, the expert translation will be used instead of auto generated translation.
+When the translation jobs run the next time, the expert translation override the auto generated translation.
 
 ## Adding a new locale translation
 Say we want to add a new language translation `ko`. We have to do the following
 1. In file `nls/strings.js` add the line `"ko": true,`
 2. In file `nls/root/strings-app.js` add the line `"LOCALE_KO": "한국어",` where `한국어` is `Korean` in Korean language.
-3. Create a new folder `nls/ko`
+3. Create a new folder `nls/ko`.
 4. Create a new file `nls/ko/strings.js` with the content `define({});`
 5. Create three new files `nls/ko/lastTranslated.json`, `nls/ko/lastTranslatedLocale.json` and
 `nls/ko/expertTranslations.json` with the content `{}`