Arduino IDE has been translated to several languages.
The localization process follows the following steps:
1. An English language source string is defined in the Arduino IDE codebase
2. The source string is pushed to Transifex
3. Community translators localize the string
4. The localization data is pulled into the Arduino IDE repository
5. The localization data is incorporated into the Arduino IDE distribution
Experience with maintenance of Arduino's localized projects indicates that the data files generated at step (4) can
appear to be the appropriate place to make edits for casual contributors not familiar with the project's sophisticated
internationalization infrastructure.
Since those files are generated by automated systems, any edits made there would only be overwritten, so it is important
to clearly communicate the correct way to make enhancements or corrections to these strings. This is accomplished by a
local readme file most likely to be seen by those working in the folder containing these files, which supplements the
existing information about translation in the project's translation guide.
Translation of the strings of the Arduino IDE UI is a valuable contribution which helps to make Arduino accessible to
everyone around the world.
Localization of the Arduino-specific strings of the IDE is done in the "Arduino IDE 2.0" project on Transifex.
Previously, the "Translation" row in the contribution methods summary table in the contributor guide entry page simply
linked to that project.
Arduino IDE also uses localized strings from several other sources:
- VS Code language packs
- Arduino CLI
Users may notice unlocalized strings or errors or areas for improvement in the existing translations and wish to
contribute translations. For this reason, it is important to also provide instructions for contributing to those other
localization data sources. The contribution methods summary table can not effectively accommodate that additional
content so a dedicated document is added for the purpose. This will also allow linking directly to that document from
related documentation or conversations.
Contributor are presented with an issue template chooser page at the start of the issue creation process.
In addition to the issue report templates, some "contact links" provide information and links to other communication
channels. In order to encourage high quality issues, a link to the "issue report guide" is included on this page.
Previously that link pointed to an incorrect URL, resulting in a 404 error for those who visited it. The URL is hereby
corrected.
On every startup, the Arduino IDE checks for new versions of the IDE. If a newer version is available, a
notification/dialog is shown offering an update.
"Newer" is determined by comparing the version of the user's IDE to the latest available version on the update channel.
This comparison is done according to the Semantic Versioning Specification ("SemVer").
In order to facilitate beta testing, builds are generated of the Arduino IDE at the current stage in development. These
builds are given an identifying version of the following form:
- <version>-snapshot-<short hash> - builds generated for every push and pull request that modifies relevant files
- <version>-nightly-<YYYYMMDD> - daily builds of the tip of the default branch
The previous release procedure caused the <version> component of these to be the version of the most recent release.
During the pre-release phase of the project development, all releases had a pre-release suffix (e.g., 2.0.0-rc9.4).
Appending the "snapshot" or "nightly" suffix to that pre-release version caused these builds to have the correct
precedence (e.g., 2.0.0-rc9.2.snapshot-20cc34c > 2.0.0-rc9.2). This situation has changed now that the project is using
production release versions (e.g., 2.0.0-nightly-20220915 < 2.0.0). This caused users of "snapshot" or "nightly" builds
to be presented with a spurious update notification on startup.
The solution is to do a minor bump of the version metadata after creating the release tag. That was not done immediately
following the 2.0.0 release. The omission is hereby corrected.
This will provide the metadata bump traditionally done before the creation of the release tag in the event the version
number of the next release is 2.0.1. In case it is instead a minor or major release, the version metadata will need to
be updated once more before the release tag is created.
On every startup, the Arduino IDE checks for new versions of the IDE. If a newer version is available, a
notification/dialog is shown offering an update.
"Newer" is determined by comparing the version of the user's IDE to the latest available version on the update channel.
This comparison is done according to the Semantic Versioning Specification ("SemVer").
In order to facilitate beta testing, builds are generated of the Arduino IDE at the current stage in development. These
builds are given an identifying version of the following form:
- <version>-snapshot-<short hash> - builds generated for every push and pull request that modifies relevant files
- <version>-nightly-<YYYYMMDD> - daily builds of the tip of the default branch
The previous release procedure caused the <version> component of these to be the version of the most recent release.
During the pre-release phase of the project development, all releases had a pre-release suffix (e.g., 2.0.0-rc9.4).
Appending the "snapshot" or "nightly" suffix to that pre-release version caused these builds to have the correct
precedence (e.g., 2.0.0-rc9.2.snapshot-20cc34c > 2.0.0-rc9.2). This situation has changed now that the project is using
production release versions (e.g., 2.0.0-nightly-20220915 < 2.0.0). This caused users of "snapshot" or "nightly" builds
to be presented with a spurious update notification on startup.
The solution is to add a step to the end of the release procedure to do a minor bump of the version metadata after
creating the release tag.
This means that the metadata bump traditionally done before the creation of the release tag will already have been done
in advance for patch releases. However, it will still need to be done for minor or major releases.
The release procedure documentation is hereby updated to produce correct tester and nightly build version precedence.
The metadata bump step is moved from before to after the tag creation step, replaced by a new step to verify the version
before the tag creation, updating it in the event it is not a patch release. Both those steps may require updating the
metadata. As an alternative to maintaining duplicate copies, each step links to a single copy of the fairly complex
instructions for doing so. The structure of the document is adjusted to accomodate this, by placing the steps of the
procedure under a "Steps" section and creating a new "Operations" section to contain any such shared content.
The release procedure is a set of steps which must be performed in a specific sequence. This fact is more effectively
communicated by formatting it as an ordered list.
Previously the instructions for updating the npm package metadata, submitting a PR for that, and merging the PR was in
the same section as the tag push instructions in the release procedure documentation.
These two operations are distinct from each other. Mashing them into a single step makes the release procedure document
difficult to read and the process more prone to error.
For this reason, a dedicated step is used for each of the two things.
* fix board selection and workspace input dialogs width and height
* use same dialog for new file and rename
* fix board list getting small when filtering
* board select dialog: show variant text when no board is found
* fix addition boards url outline
- From now on, NSFW service disposes after last reference
is removed. No more 10sec delay.
- Moved the temp workspace deletion to a startup task.
- Can set initial task for the window from electron-main.
- Removed the `browser-app`.
Closes#39
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
For security reasons, the macOS tester builds generated for PRs from forks are not notarized. Instructions are provided for
beta testing under these conditions.
Previously, the instructions for bypassing the macOS notarization requirement involved disabling macOS Gatekeeper
entirely using the spctl command. These instructions are hereby replaced by an alternative approach, where the
restriction is bypassed for the Arduino IDE application alone, via the macOS GUI.
The new approach is superior for the following reasons:
- More secure due to having limited scope
- More accessible due to the use of the macOS GUI
The readme should provide a concise overview of the essential information about the project. Additional details are
provided in dedicated documents, so the readme only needs to provide links to that information.
Documentation of how to contribute to the project gives everyone the opportunity to participate, while also reducing the
maintenance effort and increasing the quality of contributions.
This guide documents the various ways of contributing to the project.
Previously, the information about tester builds was mixed in with the documentation about building the project from
source.
The two subjects are of relevance to two distinct contribution options. Building from source will primarily be done by
developers working on the project code base. Tester builds will be used by beta testers and reviewers.
For this reason, it doesn't make sense to require beta testers to wade through a lot of development documentation not
directly related to their work in order to find the instructions for obtaining tester builds. Likewise, it doesn't make
sense to clutter up the development documentation with such information.
Moving the information about tester builds to a dedicated file makes it easier for the interested parties to find, and
also allows the creation of a comprehensive guide for beta testers without making a negative impact on the development
documentation content.
Previously, information about project development was stored in a file named BUILDING.md in the root of the repository.
That content is hereby moved to the file docs/development.md. This will provide the following benefits:
- Broaden the scope of the file to all information related to development rather than building only
- Store all documentation content under a single folder instead of randomly putting some in the root and others under
docs
The Arduino IDE has an auto update capability. A new version is checked for on every startup, and if available the user
is offered an update.
Although this update can usually be done automatically by the IDE, under some conditions this is not possible. For
example:
- The IDE package in use does not support auto update (i.e., Linux ZIP package)
- The file could not be downloaded due to a transient network service outage
In this case, the user is presented with a friendly dialog that explains the situation and links to the "Software" page
on arduino.cc, where the user can manually download and install the new version.
During the pre-release development phase of the project, the download links for Arduino IDE 2.x were on a sub-section of
the "Software" page. For this reason, the linked URL included the fragment identifier `#experimental-software` so that
the page would load scrolled down to the anchor at that section of the page.
With the 2.0.0 release, the Arduino IDE 2.x project has graduated to a production development phase. For this reason,
the download links have been moved to the top of the "Software" page and the now inaccurate `experimental-software`
anchor removed from the page.
The previous link with that fragment is still perfectly functional, but the fragment to a non-existent anchor serves no
purpose and also miscommunicates the project status to users who notice the URL that was loaded. For this reason, it is
hereby removed from the link.
During the early phase of development, the download links for the nightly build were only available from the table in the project readme.
Since that time, download links were also added to the "Software" page on arduino.cc, which is already linked to from
the readme. This means the nightly build link table is superfluous and only harms the readability of the readme.
The superfluous table is hereby removed from the readme.
An internal release procedure document was created separately from the documentation hosted in this repository. That
internal document became significantly more comprehensive and up to date than the unmaintained documentation in this
repository.
In order to avoid either the burden of maintaining two copies of the same information, or more likely the out of sync
state between the information in the two resulting from lack of such maintenance, a single document will be maintained
here in this repository.
The superior version of the information from the internal document is hereby migrated to the repository where it will be
maintained from here on.
Previously, the procedure for creating a new release of the project was included in the development documentation.
This information is distinct from the rest of the contents of that file in that it is not of any value or interest to
most contributors from the community since only project maintainers will ever create a release. This meant that it make
the document less readable and approachable without adding significant value in return.
The information is still essential to the project maintainers, so it must not be removed, but it can be moved to a
dedicated file under the existing `docs/internal/` folder that is specifically intended for storing such information.
Although the Arduino IDE's primary preferences interface provides all required configuration capabilities, advanced
users may wish to fine tune the behavior of the application or temporarily enable additional log output to use for
troubleshooting problems with the IDE.
The IDE provides such settings in a separate interface.
Previously, the existence and access procedure for these settings was undocumented.
Since this is an advanced capability, the documentation is not appropriate for inclusion with the standard user
documentation on arduino.cc. A file here in the Arduino IDE is used instead. This file will serve as a container for all
such user-targeted documentation.
- Fixed scrollbar does not reach end of list widget.
- Estimated row heights to provide better scroll UX.
- Last item's `<select>` must be visible.
Closes#1380Closes#1381Closes#1387
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
