Translation issue with message Wikimedia:Cejs-em/fr

[verdy-p]

Not clear meaning, I've never seen what looks like an abbreviation for indicating such debugging level.

The most common use of "em" is (notable by CSS) as a length measurement unit (a relative height in the context of Latin/Greek/Cyrillic alphabets or in the horizontal style of Arabic written along an horizontal line and not a series of oblique baselines for letters, broken at word boundaries, for Persian/Urdu-like styles also used for Eastern Arabic, or for some other horizontal scripts, except in Eastern Asian scripts using the sinographic composition square with different baseline metrics).

This abbreviation should be explicited, but for now I don't see any translatable replacement than just using "em", causing confusion in logs. I think it just means the same as "info" but less detailed, posting only summaries and not the extensive details within logs such as memory dumps, detailed data analysis of complex structures about how they are endoded/decoded, or some performance infos that could just be used for profiling or internal tracking helpers to locate bugs deeply hidden in private blackboxes and not exposed to public interface as they are not stable and may be replaced at any time by changing an implementation without changing the documented and expected behavior and results). In most apps I've seen, the "info", "trace" and "debug" levels are generally enough even if internally each level may group several types of trace coming from selectable sources. Logs genrally prefer just adding a separate field for showing the source of the message, independantly of the severity level.

Is there an example of usage of this "em" level anywhere ? I could not find any (and probably this is jsut somle internal featiure of Cejs itself, which is still in early development).

URL: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=cejs-em&group=cejs&language=fr

[kanasimi]

Thank you for your comments. It is true that the current word id may be confusing and the semantics are unclear.

The message will used as a tooltip of a message. For example, the "debug" in the image showing below:

And when in Chinese, it will be displayed as: (From live demo page)

I think it would be better to add a prefix. Or maybe we have a more general approach? I will add a prefix as soon as possible if it is feasible.

[verdy-p]

So what does this means ? Is it an "emphasized" variant of the "debug" log level, intended to create a visual hint when viewing a very long log ?

You seem to imply that it will just be used as a tooltip, but a tooltip is not a visual hint to help locate an item, and in fact any log line could have its own tooltip giving extra info in the popup.

I would better understand if this was used to create a real mark, like a star icon, or for coloring leading bullet icons, or to help locate infos from mutliple sources mixed in the the log with their own coloring (for that I would more likely see the usage of grouping tags, just like Gmail or GitHub tags to annotate the logs and allow extra filtering to view it with more axises of selection than just the basic debug level (which acts at run time for filtering events that will be logged or not at runtime and which may be adjusted in a global configuration of the running components emitting these logs).

Anyway I had fully terminated translating the first batch of I18n messages for French, and you've just loaded it in the project. You can now test bed it (along with a few other languages like Japanese that were borrowed from TWN) and test the effectiveness of the UI design.

---

I'm sure there will be corrections anyway, as this project is not terminated, and probably there are many missing data or computational errors with so many calendars now; as well there are certainly new ambiguities caused by different historical interpretations which were not clearly distinguised: this initial data however will certainly help historians fixing the real order of events and better analyze their causes, motications and effects, and detect what was wrong, bad assumptions, or unfair claims with political/economical/religious or criminal motivations boosted by lies or misinformation: somthing that have not stopped today and that does not help calming today's debate and decide fairly!

Knowing the history precisely, as it is, is the best way to terminate conflicts and enter into negociated arrangements and peace in the future for the global interest of everyone (especially for those that were not involved at all in these old conflicts: it's important to keep them away to force them to take a strong position that will be barriers against cooperations; we have to realize that what we don't know because it is disguised or masked, creates irrational fear, and fear initiate violent reactions in infernal loops that are hard to stop; only promoting truth by more exact and demonstratable facts allows non-involved people to remain outside the conflicts). If we don't know our history, it will repeat again as nobody will recognize their past errors.

[kanasimi]

Thank you for your interest in this project and for giving so many comments. Yes, these programs are used to show the intensity of the logs. I think other programs have similar features, I just don't know the method they use. You are more experienced, so if you have seen other programs with similar features in their translation projects, please comment, thanks.

[verdy-p]

May be "emphasis" could just be "important" in English. Some projects also use the terms "note" for their log level, or "attention" (different from "warning" which may be used for minor errors that were detected and automatically or silently fixed by using one of several alternate solutions: the log may be used to trace these automated decisions which may be reviewed and fixed again later, manually, to use another solution).

Others may use "summary" to distinguish basic log info from more detailed infos, e.g. showing totals, means or aggregated results for statistics rather than (or in addition to) a long list of individual items.

As well some logs are adding a "caused by" level (possibly with a maximum depth parameter for filtering them) for detailing logs generated by other internal layers, after logging the "trace", for example when handling runtime exceptions detected between different layers of code.

[kanasimi]

Yes, it looks like "note" would be a better wording.

I haven't implemented the "caused by" feature yet. Thanks for your comments.

[verdy-p]

Also "notice" (which is a bit more important than just a note)

Some logs also include info that are not about what is going on, but how things could work better to help get a better configuration (e.g. better performance/lower cost/less impact/less limitations/improved security/improved privacy, some legal or normative advisories): "hint", "suggestion", "help", "advice"

As well , or regularly reposted things to remember (planned events coming soon) and announcements (changes coming soon, new versions available and updates suggested or upgrades required before the service stops working; if we don't perform what is required, the component will stop working, generating errors, possibly fatal, or severely limiting some of its services). Other annoucements are changes of responsability or support, licensing changes that may need to be accepted (otherwise cooperation may stop and the existing component will be isolated for private use, outside the community in which it was operating)

As well a log may contain additional messages coming from listened subscriptions, such as "notifications" (related to a subscription account to another service which has been authorized: if that connection fails or stops responding for a too long time configured, the log would display errors with a more important level). Normally this does not block the existing component itself, but it may suggest trying something else. This allows also differents logs to correlate their events by some tracking ID/timestamp, by merging some summary events in a single stream; the component may be configured to not subscribe such external sources if these external sources are already monitored in their independant log (e.g. only viewable by separate users with other privileges: such external logs could contain private information that cannot be revealed by logging them into a publicly viewable log).

[kanasimi]

Thank you for the detailed explanation and sharing.

It looks like there is a lot more to the logging system that is worth looking into.