Typos templates (#9660)

GitOrigin-RevId: 84efa04fd56c4ce2b5414861f06de192b26b99ce

Author: olruas

docs/2.developers/4.user-guide/80.advanced/.declarative_vs_imperative/article.py

@@ -34,7 +34,7 @@
 # ```
 # we would expect three "finished" chunks: `(0,1,2)`, `(3,4,5,6)`, `(7,8)` and one unfinished chunk `(9,...)`.
 #
-# One way to do this would be imperative style: go through rows one-by-one in order storing current chunk in a state and emiting it whenever `flag` is equal to True, while clearing the state.
+# One way to do this would be imperative style: go through rows one-by-one in order storing current chunk in a state and emitting it whenever `flag` is equal to True, while clearing the state.
 # Even though, its not recommended approach, let's see how to code it in Pathway.
 
 # %%
@@ -100,7 +100,7 @@ def split_by_flag(
 # %% [markdown]
 # Instead of manually managing state and control flow, Pathway allows you to define such logic using declarative constructs like `sort`, `iterate`, `groupby`. The result is a clear and concise pipeline that emits chunks of event times splitting the flag, showcasing the power and readability of declarative data processing.
 #
-# In the following, we tell Pathway to propagate the starting time of each chunk across the rows. This is done by declaring a simple local rule: take the starting time of a chunk from previous row or use current event time. This rule is then iterated until fixed-point, so that the information is spreaded until all rows know the starting time of their chunk.
+# In the following, we tell Pathway to propagate the starting time of each chunk across the rows. This is done by declaring a simple local rule: take the starting time of a chunk from previous row or use current event time. This rule is then iterated until fixed-point, so that the information is spread until all rows know the starting time of their chunk.
 #
 # Then we can just group rows by starting time of the chunk to get a table of chunks.
 

docs/2.developers/7.templates/ETL/.alerting_on_significant_changes/article.py

@@ -99,7 +99,7 @@ class InputSchema(pw.Schema):
 )
 
 # %% [markdown]
-# To track the maximum value, we could write `input.groupby().reduce(max=pw.reducers.max(input.value))`. Here we want to keep track also *when* this maximum occured, therefore we use the `argmax_rows` utility function.
+# To track the maximum value, we could write `input.groupby().reduce(max=pw.reducers.max(input.value))`. Here we want to keep track also *when* this maximum occurred, therefore we use the `argmax_rows` utility function.
 
 # %%
 reduced = pw.utils.filtering.argmax_rows(input, what=input.value)
@@ -128,7 +128,7 @@ def accept_larger_max(new_max: float, prev_max: float) -> bool:
 result = pw.stateful.deduplicate(reduced, col=reduced.value, acceptor=accept_larger_max)
 
 # %% [markdown]
-# Now we can send the alerts to e.g. Slack. We can do it similarily as in the [realtime log monitoring tutorial](/developers/templates/etl/realtime-log-monitoring#scenario-2-sending-the-alert-to-slack) by using `pw.io.subscribe`.
+# Now we can send the alerts to e.g. Slack. We can do it similarly as in the [realtime log monitoring tutorial](/developers/templates/etl/realtime-log-monitoring#scenario-2-sending-the-alert-to-slack) by using `pw.io.subscribe`.
 #
 # Here, for testing purposes, instead of sending an alert, we will store the accepted maxima in the list.
 
@@ -147,7 +147,7 @@ def send_alert(key, row, time, is_addition):
 pw.io.subscribe(result, send_alert)
 
 # %% [markdown]
-# Let's run the program. Since the stream we defined is bounded (and we set high `input_rate` in the `generate_custom_stream`), the call to `pw.run` will finish quickly. Hovever, in most usecases, you will be streaming data (e.g. from kafka) indefinitely.
+# Let's run the program. Since the stream we defined is bounded (and we set high `input_rate` in the `generate_custom_stream`), the call to `pw.run` will finish quickly. However, in most usecases, you will be streaming data (e.g. from kafka) indefinitely.
 
 # %%
 pw.run(monitoring_level=pw.MonitoringLevel.NONE)

docs/2.developers/7.templates/ETL/.live_data_jupyter/article.py

@@ -286,7 +286,7 @@ def stats_plotter(src):
 # %% [markdown]
 # ## Jupyter Notebooks & Streaming Data in Production
 #
-# Congratulations! You have succesfully built a live data streaming pipeline with useful data visualisations and real-time alerts, right from a Jupyter notebook 😄
+# Congratulations! You have successfully built a live data streaming pipeline with useful data visualisations and real-time alerts, right from a Jupyter notebook 😄
 #
 # This is just a taste of what is possible. If you're interested in diving deeper and building a production-grade data science pipeline all the way from data exploration to deployment, you may want to check out the full-length [From Jupyter to Deploy](/developers/user-guide/deployment/from-jupyter-to-deploy) tutorial.
 #

docs/2.developers/7.templates/rag/.private_rag_ollama_mistral/article.py

@@ -192,7 +192,7 @@ class InputSchema(pw.Schema):
 # )
 # -
 
-# #### 4. Local LLM Deployement
+# #### 4. Local LLM Deployment
 # Due to its size and performance we decided to run the `Mistral 7B` Local Language Model. We deploy it as a service running on GPU, using `Ollama`.
 #
 # In order to run local LLM, refer to these steps: