Conversation
As suggested by @dvpc, refactor the PGML::format::string loop to call the appropriate method if it exists. Also all methods now have access to the block and current state of the loop to use as needed.
This was never used anywhere else (that I could find), so no need to store the current item in the PGML::format::string loop.
All of the format methods now receive a single state hash instead of the item, block, and state as separate inputs. Reduce the number of times some variables are dereferenced from the state hash. Remove some white space to minimize HTML output. Leaving newline characters `\n` alone for now.
This way only "item" methods are capitalized to distinguish them from other methods which are not a block item type.
Since newlines and spaces are extra characters to send, minimize the HTML output by removing any new line or unneeded space characters. In addition switch to using `main::tag` to create the html tags.
The table method calls itself and so it also needs to be updated to send itself a "stack" hash. Since only the `item` is used from the hash, send only that.
PGML::Format Refactoring
PTX stuff for parserRadioMultiAnswer
The first objective of this pull request is to make the output of the JSXGraph and TikZ formats for the plots.pl macro more consistent. The intent is that JSXGraph will be the primary display mode used in HTML, and TikZ the display mode in hardcopy, and the two should produce images that are a close as possible to the same. These changes are summarized as follows: * Switch the JSXGraph arrows used for curve end markers from type 4 to type 2, and tweak the TikZ arrows to match. The type 4 arrows look quite bad on curves in almost all cases. The problem is that the curve line goes all the way to the end of the arrow, and so with the really sharp arrow point of the type 4 arrow the curve can be seen sticking out past the end of the arrow. The type 2 arrows are a little better, although they still have some of the same problem. The JSXGraph documentation recommends using type 7 arrows for this reason, but those are just ugly. * Tweak the sizes of marks (or points) for the two formats. Note that the line width is now taken into account for points. TikZ does this by default for marks on a curve, but now also does this for all points even those that don't belong to a curve. JSXGraph also now takes this into account. * Open marks (`open_circle`, `open_square`, `open_triangle`, and `open_diamond`) are now implemented as the closed variant filled with white. That is how it was done already for JSXGraph, but it is now also done that way for TikZ. I have seen the same issue with TikZ that was seen with the JSXGraph format that led to doing this there. That is the curve poking into the open part of the mark. * The JSXGraph output now has ticks as well as the grid just like the pgfplots images. The tick sizes for both formats were tweaked for consistency. * The JSXGraph grid is now limited within the axes in the same way that the pgfplots grid is. Also, the JSXGraph format places the axes labels on the edges in the cases that pgfplots does so. Additiionally, the JSXGraph format no longer reserves additional space for an axis in the cases that the axis is not shown. This again is the same as what pgfplots does. * Vector/slope fields in tikz are now drawn 2 dimensionally (i.e., via addplot instead of addplot3) for pgfplots. In order to get the entire field the slope field at each level is drawn. This also means that the slope field now correctly honors the ysteps setting. Furthermore, using `addplot3` messes with the 2 dimensional axes. pgfplots automatically changes the way things are drawn as soon as `addplot3` is called. One obvious issue is that tick labels on the axes are not drawn when this is done. * The `linestyle => 'none'` setting now works differently. The previous approach was inconsistent between the two formats. It set `only marks` for TikZ, but didn't draw curves at all for JSXGraph. That means that marks would be drawn for TikZ, but nothing for JSXGraph. Also, if `fill => 'self'` was also set, then the fill would appear in TikZ, but still nothing in JSXGraph. So now `only marks` is not set for TikZ, and instead `draw=none` is set, and for JSXGraph the curve is drawn, but with `strokeWidth: 0`. So now if `linestyle => 'none'` is set, then no marks are shown (unless the `marks` option is also given) and that is consistent for both formats. If `fill => 'self'` is also set, then the fill appears for both formats, still with no curve drawn. The second objective is to add some new features and improve the way the macro works. Those changes are as follows: * Allow the grid to be shown without the axes. The `plots.pl` documentation does not indicate that hiding the axes also hides the grid, but it does. That is not desirable, and there are images in which one might want the grid without the axes. * Add axis `minor_grids` option. If this is 1 (the default), then grid lines are shown at minor tick locations, and otherwise they are not. This allows having minor ticks without associated grid lines which is sometimes desirable. The `minor` option still is the number of minor ticks (and minor grid lines if `minor_grids` is 1) and its documentation is updated to state this (instead of saying it is the number of minor grid lines even though it really was both). * Tick labels are now displayed with MathJax by default in the JSXGraph format. This can be disabled by setting the `mathajx_tick_labels` axes style option to 0. * The way the `add_label` method should be called is changed. Instead of `$plot->add_label($y, $y, label => $label, %options);` use `$plot->add_label($y, $y, $label, %options);` The first way will still work, but the second is how it should be done. The `$label` argument which is the text of the label and is an essential argument for a label, should not be an optional parameter. * Add a `rounded_corners` option to round the corners on images. This is a general option that is passed to the `Plot` method. To make this work well the `framed` TikZ package cannot be used anymore. Instead the pgfplots axes is drawn in a `savebox`. Then the axes dimensions can be obtained and used to fill the box (with the corners clipped if corners are rounded) before the save box is actually rendered, and then draw the boundary box (again with rounded corners if desired). * Add the new axes style option `axes_arrows_both` to have arrows in both directions on the axes. * Move the JSXGraph board setup into a JavaScript file. The macro just passes the options for the board to the JavaScript. This results in a much smaller footprint in the generated page HTML sent to the browser, particularly if multiple images are in one problem. In addition, more features can be added in the JavaScript without adding to that footprint (such as the code for displaying tick labels as fractions, mixed numbers, and scientific notation -- see below). The new JavaScript file and the `jsxgraphcore.js` file both have the `defer` attribute. The `jsxgraphcore.js` file should have been loaded deferred before. * There are no font sizes corresponding to all of the basic TeX font size declarations except `scriptsize` and `footnotesize`. So 'tiny', 'small', 'normalsize', 'large', 'Large', 'huge', and 'Huge' are the available font sizes. The `medium` and `giant` sizes from before are marked as deprecated, but still work. `normalsize` replaces `medium` and `Large` replaces `giant`. The reason that `scriptsize` and `footnotesize` were not included is because there isn't really room between `tiny` (8) and `small` (10) in the JSXGraph translation of sizes to put anything in between. I suppose one could be added at size 9, but you can barely see the difference, and at such small sizes I am not sure it matters. * Add an `add_point` method, and deprecate the `add_stamp` method. The points added by the `add_point` method are basically datasets consisting of a single point, but are drawn after everything else so that they appear on top. * Vector/slope fields are drawn in the order that the author adds them to the plot. Previously they were drawn after everything else which was just wrong. That meant that if a curve was added to the plot after a vector field it would be drawn behind the vector field (barring the use of a layer), and that really should not be the case. This is also needed in the code to ensure that points are drawn after everything else, and the reuse the existing dataset drawing code. * An invalid color name no longer causes the problem to fail to render. Furthermore, SVG color names can be used directly without being defined by the `add_color` method. See section 4.3 of the TeX xcolor package for a list of SVG color names (https://ctan.mirrors.hoobly.com/macros/latex/contrib/xcolor/xcolor.pdf). Those work for both TikZ and JSXGraph directly. * Add `layer` and `fill_layer` options. This allows fill regions to be drawn on the axis background layer, and is a much better approach than using the `axis_on_top` option. Using the `axis_on_top` option results in the axis being on top of all curves and function graphs, and generally looks bad. In addition, the `axis_on_top` option is not implemented at all for the JSXGraph format. By using layers the fill can be drawn on the background and the curve on the foreground. Note that the "standard" layer set for the TikZ format is now different than the pgfplots default. The "axis tick labels" is after the "pre main" and "main" layers. This is consistent with where JSXGraph places them, and is better than what pgplots does. Axis tick labels are textual elements that should be in front of the things that are drawn, together with the "axis descriptions". On the other hand, the JSXGraph axis layer is adjusted to match the pgfplot axis layer, which is above the axis tick layer. Further adjustments may be needed, but for now this gives a rather consistent match up. I decided to leave the general `layer` option exposing all layers (we discussed turning that into a `draw_on_background` option only). Instead I tweaked the pgfplots standard layer and the JSXGrpah default layers to make them more consistent. Also, I saw another use where another layer is best. That is for vector/slope fields. Those should be drawn on the `pre main` layer so that the arrows are in front of the grid and axis lines, but behind other curves and textual components such as the tick labels and axis labels. * The fill between fill regions are no longer deferred until after everything else is drawn. That causes unintended side effects. Particularly, it is inconsistent with how `fill => 'self'` is done. In that case the fill is done immediately. As a result if both a "self" fill and a "fill between" fill are used, then the "self" fill ends up behind the "fill between" fill regardless of the order the two are created. So this respects the order of creation which is the author's intended order. Note that to protect against this the names of datasets that have been created are tracked, and if an author attempts to fill between a dataset and another dataset that has not yet been created, then the fill is not created and a warning is issued. * The documented default for the `arrow_size` option was 10. That was the default for the TikZ format, but the actual JSXGraph default was 8. The two formats certainly cannot use different defaults. So now the default is 8 for both formats and documented as such. Furthermore, with the mark size tweaks mentioned earlier, that default (and other size settings) are similar for both formats. * Add tick_distance, tick_scale, and tick_scale_symbol options. The `tick_distance` and `tick_scale` options give more fine grained control over tick placement than the former `tick_delta` option. The `tick_delta` option is all but deprecated (but I did not say so). The `tick_delta` is the product of the `tick_distance` and the `tick_scale`. The point is that the `tick_distance`, `tick_scale`, and `tick_scale_symbol` can be used to do things such as having ticks at multiples of `pi` and labeled as such. For example, if `tick_distance => 1 / 4`, `tick_scale => pi`, and `tick_scale_symbol => '\pi'`, then the ticks will be labeled `0.25\pi`, `0.5\pi`, `0.75\pi`, `\pi`, etc., and of course these ticks will appear at those actual distances on the axis (the `tick_delta` will be `pi / 4`). * Add axis `tick_label_format` option. This can be one of "decimal", "fraction", "mixed", or "scinot" (default is "decimal"). It should be clear what those values mean. Note that this works well with the above options. So with the example for those options above and `tick_label_format => "fraction"`, the tick labels will be `\frac{1}{4}\pi`, `\frac{1}{2}\pi`, `\frac{3}{4}\pi`, `\pi`, etc. * Add `extra_js_code` and `extra_tikz_code` options. These can be used to add extra JavaScript or TikZ code to draw things that are not covered by the macro directly. These are advanced options that should be used with care, only by those that really know what they are doing, and always both options used together to keep the JSXGraph and TikZ output formats the same. * Fix a bug that prevented functions defined by Perl functions from appearing at all in the TikZ format. * Some issues with the `Plots::Data::function_string` method were fixed. First the absolute value was not working. The issue is the the absolute value in a MathObject does not stringify as the `abs` function. Something like `abs(x)` stringifies as `|x|`. The `function_string` parsing approach cannot handle something like that. To fix this a new `stringifyAbsAsFunction` context flag was added, and if that flag is set for the context the absolute value stringifies as `abs`. So `abs(x)` stringifies as `abs(x)`. In addition there are no JavaScript functions `Math.ln`, `Math.arcsosh`, or `Math.arctanh`. So those "tokens" were fixed with the correct JavaScript functions which are `Math.log` (which is the natural log), `Math.acosh`, and `Math.atanh`, respectively. Note that the `GD` image format (the `Plots::GD` package) for the plots macro has been removed. That format shouldn't be used anyway as it generates low quality graphics (at least in its current form).
This is accomplished using the spath3 TikZ library. To make this work all paths need to be named, and if a draw and fill are done separately, then the fill just uses the path from the draw so it does not need to be recomputed. Additionally refactor multipaths to make the TikZ format much more efficient, as well as to make multipaths more versatile. Both the TikZ and JSXGraph formats are done differently now. They both join the paths in a completely different way that does not use the x transform (so the `function_string` x transform code is now never used in fact). Instead in TikZ the spath3 TikZ library is used and the paths are drawn individually, and then concatenated. For the JSXGraph format the paths are created individually and their data points concatenated to form a single curve. The result allows for more versatility since now paths do not need to end where the next path starts. The paths are connected by a line segment if needed. For JSXGraph this just works with the concatenation approach. For TikZ this has to be added. Note this actually happened before with the previous TikZ implementation, but not for the JSXGraph implementation. The most important thing is that with this implementation the time that it takes for TeX to run for multipaths is greatly reduced. For the example in the POD and the current TikZ code it takes about 3 seconds for TikZ to run, and the CPU usage is quite high. If the fill and draw are on different layers so that the fill and draw occur separately, it takes even longer. With the new code it takes about 1 second for either case and the CPU usage is much less. One reason for this is that the number of steps needed with the new approach (which is now per curve) is much less. Previously 500 steps were used (by default) for the entire curve. Now 30 (by default) are used for each curve. Note that this can now be optimized and steps set per curve. There is also a new `cycle` option for multipaths. If `cycly => 1` is set for a `multipath`, then a line segment will be inserted from the end of the last path to the start of the first in the case that the last path does not end at the start of the first, thus closing the path.
…ns in the TikZ format. This was an inconsistency between the two formats. Basically, the JSXGraph format did not honor the function max if `continue` or `continue_right` was set, but the TikZ format did. This could result in a function graph continuing to the right in the JSXGraph format, but not in the TikZ format (assuming the board bounds go further to the right). This just makes the TikZ output use the axes max instead of the function max in this case. Of course if `continue` and `continue_left` are set then the axes min is used instead of the function min.
Adding 360 degrees to the computed theta1 if theta1 is negative and independently doing the same for theta2 is incorrect. For example, if theta1 is negative, but theta2 is positive, then that can result in theta1 being greater than theta2 and give an unintended result, and is inconsistent with the JSXGraph result in this case. What should happen is that 360 be added to theta2 if theta2 is less than or equal to theta1, and theta1 should never be modified. This gives consistent results with the JSXGraph arc in all cases (except the case below, and that is made consistent with the JSXGraph change in this commit). JSXGraph is not capable of drawing a 360 degree arc (i.e., the case that an arc starts and ends at the same point). So if the start and end point are the same, then move the end point back around the circle a tiny amount so that JSXGraph will draw the entire circle.
There are two new options for positioning labels, `anchor` and `padding`. The `padding` option makes it possible for the author to easily set the padding for the label. This is css padding in pixels for the JSXGraph format, and the value of the node `inner sep` in points for the TikZ format. The `anchor` option is an alternate positioning approach to the current `h_align` and `v_align` approach. See the POD documentation for a (hopefully) good explanation of this option. Basically, in the TikZ format this is the value for the node `anchor` option in degrees. Since JSXGraph doesn't provide such an option, this had to be implemented using a transformation. This is useful for positioning labels for angles.
These options allow restricting the fill region in the y range when filling between curves. Furthermore, these options can be combined with the fill_min and fill_max options to restrict the fill region to a rectangle.
There are times that you don't want the arrows going in both directions on both axes. For instance, if the x-axis doesn't go to the left, but the y-axis does go both up and down.
This still allocates space initially as it did before, but that is merely to let the JavaScript know where to make adjustments and so that there is space for the axes and tick labels to render. Then the JavaScript adjusts the space after the initial render. This ensures that there is enough space for the labels as well as make the spacing nicer when the board is resized in the imageview dialog.
…SimpleGraph.pl` macro.
More plots improvements
…ave been implemented before. If the `scaleX`, `scaleSymbolX`, `scaleY`, `scaleSymbolY`, or `coordinateHintsType` options are used then the axis ticks and labels are adjusted in the JSXGraph HTML output for the GraphTool, but not in hardcopy. This was an oversight that I didn't do this when these options were implemented. I also added minor ticks to the hardcopy. Those were also never implemented. The documentation for the `scaleX` and `scaleY` options was also corrected. I misstated the way that this is handled by JSXGraph.
…mentation. This is intended to replace the openwebwork/pg-docs repository. The approach in that repository has some issues. * The workflows must be manually triggered in sequence. * It isn't tied to the PG repository and so can become and in fact is now out of date. * It unnecessarily commits the generated documentation files to a repository as well as publishing them on GitHub pages. * It uses the `bin/dev_script/generate-ww-pg-pod.pl` script from the webwork2 repository to generate the PG and webwork2 POD, and the webwork2 POD should not be on a site that is intended for PG documentation. Furthermore, the generated html POD site does not fit into the PG documentation site well. For, example there is no link to get back to the main PG documentation index page, and it is labeled as WeBorK documentation, not PG documentation. The single workflow added in this pull request runs anytime anything is merged into the main branch. It can also be manually triggered but that generally won't be needed. This means that anytime a new version of PG is released the documentation will automatically be updated for that release. The workflow generates the PG POD and sample problem documentation and publishes the documentation to the PG GitHub pages site at https://openwebwork.github.io/pg. The generated documentation is not committed to a repository. It is published to the pages site, and that is enough. A new `bin/generate-pg-pod.pl` script is added that generates only the PG POD. The generated html is tailored for the PG documentation on GitHub pages. There is some minor redundancy as there are some files that are now in both the webwork2 and PG repositories (needed for both the `generate-ww-pg-pod.pl` and `generate-pg-pod.pl` scripts). However, it certainly would not be a good idea to have the PG repository depend on the webwork2 repository for the `generate-ww-pg-pod.pl` script, and as mentioned that script doesn't really generated the right HTML to begin with. Move the `SampleProblemParser` module into the `WeBWorK::PG` namespace. All of the other modules in the root namespace in the PG repository are directly for problem rendering except this one. It is out of place. So it is now the `WeBWorK::PG::SampleProblemParser` module. Change the options for the `parser-problem-doc.pl` script and the `WeBWorK::PG::SampleProblemParser` module. Using underscores for options is annoying. Underscores require an extra keyboard button press (the shift key), and underscore are not standard for command line options. Also the `pod_root` and `pg_doc_home` options are badly named. The `pod_root` option name seems to indicate it should be the directory location for the POD, but it is a URL. So make that clear by renaming it to `pod-base-url`. The `pg_doc_home` is not the URL for the PG documentation home, but for the sample problem base URL. So rename that to `sample-problem-base-url` (and its shortcut from "h" to "s"). Also change the corresponding variable names in the `SampleProblemParser.pm` module. Copy the PODParser.pm and PODtoHTML.pm modules from the webwork2 repository to lib/WeBWorK/Utils where webwork2 can also use them. Those modules will be deleted from the webwork2 repository. Copy podviewer.css and podviewer.js from the webwork2 repository into htdocs/js/PODViewer, also where webwork2 can use them. The files will be deleted from the webwork2 repository. Copy the bin/dev_scripts/pod-templates category-index.mt and pod.mt files into assets/pod-templates here, and make changes to the files so that they will work for both webwork2 and pg. The files will also be deleted from the webwork2 repository. Add the sample problem and macro POD search to PG docs. The sample problem and macro POD search data is generated by the `WeBWorK::PG::SampleProblemParser::getSearchData` method. This is used by webwork2 and the `bin/generate-search-data.pl` script. The script is very simple. It just calls the method passing in the file name to save the data to. The workflow runs the script and copies the resulting file to the PG github pages site. The `assets/stop-words-en.txt` file is moved here from the webwork2 repository since the `WeBWorK::PG::SampleProblemParser::getSearchData` needs it. The `htdocs/js/SampleProblemViewer/documentation-search.js` is moved from the webwork2 repository (webwork2 uses it from here now), and this is also copied to the PG github pages site in the workflow. It is slightly modified to work for both webwork2 and on the PG github pages site.
The latest version of JXSGraph is 1.12.2. However, that version (and all versions after 1.11.1) have an issue with tab order when keyboard events are enabled. Basically, it is impossible to use shift-tab to progress in reverse in the tab order. See jsxgraph/jsxgraph#773. So to work around that I had to override the board's `keyDownListener` method with one that does not call `preventDefault` on a keydown event that comes from a tab key being used. This override can be removed after upgrading to the next version of JSXGraph after 1.12.2 as this has been fixed in their develop branch and that fix will be in the next release. Another thing that is a bit annoying with versions 1.11.1 and later is that you now have to set the tabindex on elements that are not fixed yourself. By default they set the tabindex to -1, which means they are not in the tab order. So `gt.definingPointAttributes` is now a function, and if it is called with `gt.isStatic` true, a tabindex of -1 is used, but if `gt.isStatic` is false, then a tabindex of 0 is used (and so those points will be keyboard focusable).
The code looks for the `enter_key_submit` submit button in the DOM, and if that is found then it clicks it. However, it doesn't return after that, but continues on the the later code in the method none of which should occur if that button is found. The later code executes the "gateway quiz" fallback which clicks the submit button with the name "previewAnswers". However, there is also a button with that name in homework. The behavior is different in different browsers with this. In Firefox the first button clicked seems to be what is in effect. However, in Google Chrome the second button clicked is in effect. So the desired behavior occurs in Firefox, but not in Google Chrome. What needs to happen is that if the `enter_key_submit` input is found, then that should be clicked, and the method should return. There is no need for the fallback click of the submit button with the id `previewAnswers_id` otherwise. Instead just click the submit button with the name `previewAnswers` which is present in both homework sets and tests. I certainly thing that this should be a hotfix.
…ion-workflow Add a workflow to generate and publish PG POD and sample problem documentation.
Implement several options for the GraphTool in hardcopy that should have been implemented before.
Upgrade JSXGraph to the latest version and fix the graphtool for that.
Fix the enter key behavior for MathQuill inputs.
Apparently I didn't have crate-ci/typos setup when I made that pull request.
Fix postitive typo from #1454.
There have been some string changes, and so it would be good to do this again before the release. Once this merged and synchronized to develop, then Transifex will pull the changes. Then I will pull all of the language `.po` files back to the release candidate.
Update the `pg.pot` file once more.
33% of minimum 1% translated source file: 'pg.pot' on 'fr_CA'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…ebe0c8 Updates for file lib/WeBWorK/PG/Localize/pg.pot in fr_CA [Manual Sync]
45% of minimum 1% translated source file: 'pg.pot' on 'el'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…f13c61 Updates for file lib/WeBWorK/PG/Localize/pg.pot in el [Manual Sync]
8% of minimum 1% translated source file: 'pg.pot' on 'ko'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…80e0bf Updates for file lib/WeBWorK/PG/Localize/pg.pot in ko [Manual Sync]
3% of minimum 1% translated source file: 'pg.pot' on 'tr'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…1266f2 Updates for file lib/WeBWorK/PG/Localize/pg.pot in tr [Manual Sync]
2% of minimum 1% translated source file: 'pg.pot' on 'ru_RU'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…5ad772 Updates for file lib/WeBWorK/PG/Localize/pg.pot in ru_RU [Manual Sync]
3% of minimum 1% translated source file: 'pg.pot' on 'zh_CN'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…30f926 Updates for file lib/WeBWorK/PG/Localize/pg.pot in zh_CN [Manual Sync]
27% of minimum 1% translated source file: 'pg.pot' on 'cs_CZ'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…9bc1ea Updates for file lib/WeBWorK/PG/Localize/pg.pot in cs_CZ [Manual Sync]
57% of minimum 1% translated source file: 'pg.pot' on 'he_IL'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…0048f2 Updates for file lib/WeBWorK/PG/Localize/pg.pot in he_IL [Manual Sync]
4% of minimum 1% translated source file: 'pg.pot' on 'fr'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…0385d9 Updates for file lib/WeBWorK/PG/Localize/pg.pot in fr [Manual Sync]
6% of minimum 1% translated source file: 'pg.pot' on 'es'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…cb1668 Updates for file lib/WeBWorK/PG/Localize/pg.pot in es [Manual Sync]
14% of minimum 1% translated source file: 'pg.pot' on 'de'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…9dfc2b Updates for file lib/WeBWorK/PG/Localize/pg.pot in de [Manual Sync]
5% of minimum 1% translated source file: 'pg.pot' on 'hu'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
2% of minimum 1% translated source file: 'pg.pot' on 'zh_HK'. Sync of partially translated files: untranslated content is included with an empty translation or source language content depending on file format
…362c87 Updates for file lib/WeBWorK/PG/Localize/pg.pot in hu [Manual Sync]
…e30cf1 Updates for file lib/WeBWorK/PG/Localize/pg.pot in zh_HK [Manual Sync]
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is the release candidate for WeBWorK 2.21. Please re-target any pull requests that you want to get into the release for this branch.