alm chung 정앎

alice = alm = mira chung

p5.js: Friendly Error System


Open source contribution to p5.js (javascript library for creative coding).
2017. 2021-

p5.js Friendly Error System (FES) provides supplementary error messages to make debugging process more accessible.

︎︎︎ FES project write up

︎︎︎ Current FES project page

︎︎︎ p5.js github repo


Starting from examining language-specific common error cases, I developed FES which creates console messages that can hint at the debugging solution rather than throw an error and exit.

FES live example
FES live example (with Korean intro)





JavaScript often allows “silent failures”, meaning the code will fail to execute the expected behavior without a warning (i.e. error messages) from the debugger. For example, JavaScript doesn’t support type checking by default, making errors in parameter entry harder to detect for new JavaScript developers.


From the 2017 FES project write-up:

Consider how much time we spend on debugging. It’s easy to imagine how an effective debugger can cut down development time. What we often overlook is the mood we are in during the programming experience. After all, at the core, the experience of programming resembles an endless back-and-forth communication between the programmer and the debugger.

The voice of a debugger will have an impact on new developers’ first impression and following coding experience. This is why designing a friendly debugger and error system is essential for projects with an outreach mission such as Processing and p5.js. Having a well-designed debugger written in the right tone can lower the barrier for inexperienced users.

p5.js’s new feature, the Friendly Error System (FES), was developed with this idea in mind. Started from examining language-specific common error cases, we developed FES which creates console messages that can hint at the debugging solution rather than throw an error and exit. JavaScript often allows “silent failures”, meaning the code will fail to execute the expected behavior without a warning (i.e. error messages) from the debugger. For example, JavaScript doesn’t support type checking by default, making errors in parameter entry harder to detect for new JavaScript developers.

So far, FES is able to detect and print messages for two kinds of errors: (1) validateParameters() checks a function’s input parameters to confirm it matches the inline documentation and (2) friendlyFileLoadError() catches file loading errors. We have integrated these two kinds of error checking to a selected set of p5 functions, but developers can add them to more p5 functions, or their own libraries, by calling the above FES functions. FES provides a generalized error message generation system, so more error types can be implemented in the future.

To help beginners without requiring additional setup, FES is enabled by default in p5.js. In p5.min.js, it is completely disabled for efficiency. We understand that having an assistant system like FES can be counter-productive and it is possible to easily disable FES by setting `p5.disableFriendlyErrors = true;. I’ll be using p5.js with the default setting in all the following examples.

Without further delay, let’s see FES in action in the ︎︎︎ p5.js Web Editor (FES live example).

p5.js: i18n Guidelines for Friendly Errors


Open source contribution to p5.js (javascript library for creative coding).
2021-ongoing.

I am co-writing the internationalization (i18n) guidelines for making friendly errors, supplimentary error messages written in accessible language.

It is a collection of essays that discuss issues arising from the internationalization process from the perspective of the destination culture (as opposed to the source culture where technology disperse out).




In literature, as Eco put, “translation is always a shift, not between two languages but between two cultures.” What about the internalization of software?

As a part of Google Season of Docs, I am co-developing the internationalization (i18n) guidelines for error messages. The guidelines are for the p5.js library from Processing Foundation and its future contributors. Although we call this document “guidelines” for convenience, it is rather a collection of essays that discuss issues arising from the internationalization process from the perspective of the destination culture (as opposed to the source culture where technology disperse out).

The co-writing project has grown out of the co-translation of the p5.js friendly error messages, collaborating with artists in Korea. I thank my co-writers 전유진(Youjin Jeon) and 염인화(Inhwa Yeom), as well as our editor 이지현(Jihyun Lee) for their time and valuable conversations.



Rationale


For an open-source project aspiring to reach international learners, it makes sense to try to reach people who are unable to navigate the English-dominant open-source platforms. For non-English speaking communities, choosing the instruction language for technology can decide the community’s competitive edge in the global market, which conflicts with a critical issue of technocultural sovereignty. On top of that, selecting a language for technology can further create additional barriers and divisions within the community.

Through this co-writing project, I wanted to hear from a non-English speaking community (in this case, artists based in Seoul). We had fruitful conversations on the internationalization of the FES and related technocultural issues during the process, which I want to share with the p5js community.


Goals


  1. To generate the first version of the p5.js FES translation in Korean.
  2. To develop the first version of internationalization and writing guidelines for friendly errors.
  3. To collect feedback on the p5.js FES (and its documentation) from Korean communities.
  4. To archive current issues on technology and language in Korean communities.
  5. To set a precedent on translating the p5js FES collaborating with a local community.


Participants


Co-writers:
Editor:
  • 이지현 (Jihyun Lee): Korean publishing editor based in South Korea
  • (Looking for an English editor!)


Process


This section lists the entire process of <i18n and Writing Guidelines for Friendly Errors>. We are currently working on Step 3 (Nov 21, 2021). We expect to finish writing the guidelines around the end of 2021 and conduct interviews in early 2022.
  1. Translate FES
    — The participants independently translated FES messages (~40 messages / 70 lines) from English to Korean.
    — The organizer gathered machine translations (Google Translate, Naver Papago) of FES messages.
  2. Edit the translated text
    — 2-A. The organizer selected five messages from the gathered translated text.
    — 2-B. The participants edited/commented on the selected translated messages from step 2-A.
  3. Generate translation guidelines (we are here)
    — The participants will collectively write the internationalization and writing guidelines for FES based on the activity from step 2-B.
  4. Conduct 1:1 Interviews on internationalization
    — The organizer will interview each participant to share their experience as a tech mediator, centering on language-technology relations and translation. The interviews will be archived as a part of the project. (3 interviews including the Korean editor interview)
    — The organizer will interview past and current p5js translation and internationalization contributors.
  5. Publish FES Korean translation on the p5.js repo
  6. Publish i18n and Writing Guidelines for Friendly Errors on the p5.js repo


Preliminary Results


Examples of different translations by writers and machine translation tools are shown above. For the FES welcome message, six different translations were generated, and a discussion on what is ‘friendly’ in the context of Korean culture ensued.
Our team first translated the existing English error messages of FES. In addition to our drafts, we added machine translations from popular translation tools used in Korea: Google Translate and Naver Papago for reference.


We then generated comments on some selected translations, followed by an asynchronous critique session on the translations. We collected all notes and scripts generated from the critique session to identify 5–6 core issue topics for creating the internationalization and writing guideline.

Below is the list of these topics:
  • How to create a voice for FES?
    — Who is our audience? How should we think of skill and ability if we design for accessibility?
    — What is ‘friendly’ for Korean people? Scale and scope of friendliness within the context of Korean culture
    — How to create a conversational agent persona based on the community Code of Conduct? (FES as a member of the p5.js community)
  • What are the challenges for translating from English to Korean?
    — Challenges of translating domain-specific, technical terms
    — Resources for Korean translation (writing effectively and clearly in Korean)
  • Who/what are we connecting through translation?
    — Machine translation for technical translation and other platforms for translation

Last updated: 11/2021